Здравей, Хабр!
Имаме нова важна тема — качествена разработка на IT продукти. Често говорим на HighLoad++, как да направим натоварените услуги бързи, а на Frontend Conf — страхотен потребителски интерфейс, който не забранява. Редовно имаме теми за тестване, а на DevOpsConf обсъждаме интеграцията на различни процеси, включително тестването. Но по въпроса какво можем да наречем качество в цялост и как да работим комплексно върху него — няма.
Ние ще го поправим на — ще развиваме културата да мислим за качеството на крайния продукт за потребителя на всяка етап от разработката. Приемането на неупорстване в своята зона на отговорност и свързването на качеството не само с тестерите.
Под катина ще говорим с председателя на програмния комитет, ръководителя на тестването в Тинькофф.Бизнес, създателя на рускоезичното QA общество Анастасия Асеева-Нгуен за нивото на индустрията QA и мисията на новата конференция.
— Настя, здравей. Разкажи, моля, за себе си.
Анастасия: Аз ръководя тестването в банката, отговарям за много голям екип — повече от 90 души. Имаме важна бизнес линия, отговаряме за екосистемата за юридически лица.
Учих на мехмата и първоначално исках да стана програмист. Но когато ми предложиха интересна позиция, реших да опитам като тестер. Както се оказа, това е моето призвание. В момента виждам цялата си работа именно в този сектор.
Аз съм запален привърженик на дисциплината Quality Assurance. Не ми е безразлично какви продукти се създават, как се отнасят към качеството в компанията, в екипа и, по принцип, в процеса на разработка.
За мен е очевидно, че общността в тази област е недостатъчно зряла, поне в Русия. Не винаги разбираме, че осигуряването на качеството не е само фактът на тестването на приложението за съответствие на изискванията. Искам да променя тази ситуация.
— Използваш термини Quality Assurance и тестване. В очите на обикновения човек тези два термина много често се пресичат. С какво се различават, ако се задълбочиш?
Анастасия: По-скоро, не се различават. Тестването е част от дисциплината Quality Assurance, това е непосредствена дейност - самият факт, че нещо тествам. Наистина има много видове тестване, а за различните видове тестване отговарят различни хора. Но у нас в Русия, когато се появи вълна от аутсорсери, които предоставят тестери на компании, тестването се сведе до един единствен вид.
В повечето случаи са ограничени само до функционалното тестване: проверяват, дали това, което са написали разработчиците, отговаря на спецификацията и толкова.
— Разкажи, моля, какви още дисциплини за осигуряване на качеството съществуват? Какво още, освен тестването, влиза тук?
Анастасия: Quality Assurance — това, преди всичко, е за създаването на качествен продукт. Тоест ние си задаваме въпроса, какви атрибути на качеството трябва да притежава нашият продукт. Съответно, ако това разбираме, можем да съпоставим, кой влияе на тези атрибути на качеството. Не е важно, разработчик, проектен мениджър или продуктов мениджър — това е човек, който влияе на развитието на продукта, на неговия беклог, на неговата стратегия.
Тестировачът започва да осъзнава своята роля. Той разбира, че задачата му не е само да тества за съответствие с изискванията, но и да тества самите изисквания, да поставя под съмнение формулировките, които идват от продуктовия мениджър, да разкрива всички неявни изисквания и очаквания на клиента. Когато предоставяме нова функционалност на нашия клиент, наистина трябва да отговорим на неговите очаквания и да решим неговите проблеми. Ако мислим за всички атрибути на качеството, клиентът ще бъде доволен и ще разбере, че компанията, чийто продукт използва, наистина се грижи за неговите интереси, а не работи по принципа "каквото и да е, само да пуснем нова функция".
— Изглежда, че това, което описваш сега, е задача на продуктовия мениджър. Това, всъщност, не е за тестване и не е за качество — всъщност е свързано с управлението на продукта, нали?
Анастасия: Включително. Quality Assurance не е дисциплина, за която отговаря един конкретен човек. В момента има популярно направление в тестването, подход, който се нарича Agile TestingВ неговото определение ясно се посочва, че това е екипен подход към тестването, който включва определен набор от практики. За реализирането на този подход отговаря целият екип, дори не е задължително в екипа да има тестировчик. Целият екип е насочен към предоставяне на стойност на клиента и тази стойност да отговаря на неговите очаквания.
— Получава се, че качеството се пресича почти с всички околни дисциплини, налагайки рамки на всичко около нас?
Анастасия: Вярно. Когато се замислим за това, което искаме да създадем качествен продукт, започваме да мислим за различните атрибути на качеството. Например, как да проверим, че наистина сме направили функция, която е необходима на нашия клиент.
Тук се появява такъв вид тестване, като UAT (потребителско приемно тестване). За съжаление, в Русия той рядко се практикува, но понякога е присъстващ в SCRUM екипи, като демонстрация за крайния клиент. В чуждестранни компании това е доста разпространен вид тестване. Преди да отворим функционалността за всички клиенти, първо правим UAT, т.е. каним крайния потребител, който провежда тестване и веднага дава обратна връзка – дали продуктът съответства на очакванията и решава проблемите. Само след това се случва мащабиране на всички останали клиенти.
Т.е. насочваме се към бизнеса, към крайния клиент, но в същото време не забравяме за технологията. От технологиите също много зависи качеството на продукта. Ако имаме лоша архитектура, няма да можем бързо да пускаме функции и да отговаряме на очакванията на клиента. Може да има много бъгове при опит за мащабиране, или при опит за рефакторинг можем да повредим нещо. Всичко това ще влияе на удовлетвореността на клиента.
От тази гледна точка, архитектурата трябва да бъде такава, че да можем да пишем чист код, който да позволи бързо внасяне на промени и да не се страхуваме, че всичко ще се разпадне. За да не се разтеглят итерациите за доработка за няколко месеца просто защото имаме твърде много легаси и трябва да правим дълги етапи на тестване.
— Вече са ангажирани разработчици, архитекти, продуктоведи, продуктови мениджъри, самите тестировчици. Кой още е ангажиран в процеса на осигуряване на качеството?
Анастасия: Сега да си представим, че вече сме предоставили функция на клиента. Очевидно е, че трябва да следим качеството на продукта, дори когато той е вече в продукция. На този етап могат да се проявят ситуации с неочевидни сценарии, така наречените бъгове.
Първият въпрос е как работим с тези бъгове след като вече сме пуснали продукта? Как, за пример, реагираме на натоварването? Клиентът няма да е особено доволен, ако страницата зарежда повече от 30 секунди.
Тук влиза в играта експлоатацията или, както я наричат сега, DevOps. Всъщност това са хората, отговарящи за експлоатацията на продукта, когато той е вече на прод. Включени са различни видове мониторинг. Има дори подвид тестване – тестване на прод, когато си позволяваме нещо да не тестваме преди пуска и да го тестваме директно на прод. Това е ред мероприятия от гледна точка на организацията на инфраструктурата, които позволяват бързо реагиране на инцидент, влияние върху него, корекция.
Инфраструктурата също е важна. Често се случват ситуации, в които по време на теста е невъзможно да се уверим, че имаме всичко, което наистина искаме да предоставим на клиента. Пускаме на прод – и започваме да улавяме неочевидни ситуации. А всичко това, защото инфраструктурата в теста не съответства на инфраструктурата на прод. Оттук произтича нов вид тестване – тестване на инфраструктурата. Това са различни конфигурации, настройки, миграция на бази данни и т.н.
Оттук възниква въпросът – възможно ли е, екипът да използва инфраструктурата като код.
Вярвам, че инфраструктурата пряко влияе на качеството на продукта.
Надявам се на конференцията да има доклад с реален случай. Напишете ни, ако сте готови да споделите от личния си опит как инфраструктурата като код влияе на качеството. Инфраструктурата като код позволява по-лесно проверяване на всички настройки и тестване на неща, които иначе просто не са възможни. Затова в процеса на разработка на качествен продукт се включва и експлоатацията.
– А какво ще кажете за аналитиката и документацията?
Анастасия: Това се отнася по-скоро до системи за предприятия. Когато говорим за предприятия, в главата ни веднага идват такива хора като анализатори и системни анализатори. Понякога ги наричат технически писатели. Те получават задача за написване на спецификация и я изпълняват, например, за месец.
Доказано, че писането на такава документация води до много дълги итерации на разработката и удължени периоди на доразработка, тъй като по време на тестовете се откриват бъгове, което води до връщания. В резултат на това се появяват много цикли, които увеличават разходите за разработка. Освен това, това може да въведе уязвимости. Изглежда, че сме написали референтен код, но след това сме направили промени, които разбиват идеално обмислената архитектура.
В крайна сметка получаваме не съвсем качествен продукт, защото в архитектурата вече са се появили лепенки, кодът в някои места не е достатъчно покрит с тестове, защото сроковете настигат, трябва по-бързо да затворим всичките бъгове. А всичко това е, защото в първоначалната спецификация не бяха взети предвид всички моменти, които трябва да бъдат реализирани.
Разработчиците не са злодеи и не пишат специално код с грешки.
Ако бяхме замислили спецификация, в която да са озвучени всички необходими моменти, всичко щеше да бъде реализирано точно както трябва. Но това е утопия.
Вероятно, написването на идеална спецификация на 100 страници е невъзможно. Затова трябва да се помисли за алтернативни начини на написване на документация, специфициране, поставяне на задачи, които да ни приближат до това разработчикът да прави точно това, което е необходимо.
Тук идват на ум подходи от Agile - потребителски истории с критерии за приемане. Това е по-подходящо за екипи, които работят с малки итерации.
— Какво е мнението ти за тестовете на използваемост, удобството на продукта, дизайна?
Анастасия: Това е много важен момент, тъй като в екипа има дизайнери. Често дизайнерите се използват като услуга - или отдел дизайнери, или дизайнер на аутсорс. Често се случва дизайнерът да е слушал продуктовия човек и да направи това, което е разбрал. Но когато започнем с итерацията, се оказва, че всъщност не е направено това, което сме очаквали: дизайнерът е пропуснал нещо, не е обмислил до край поведението, тъй като не е в екипа и не е в контекста, или фронтенд разработчикът не е разбрал напълно неговия макет. Може да са нужни няколко итерации само поради проблем с разбирането на дизайна от фронтенд разработчика.
Плюс има още един проблем. В момента дизайн-системите стават все по-популярни. Те са на мода, но ползите от тях не са напълно очевидни.
Сблъсквам се с мнението, че дизайн-системите улесняват разработката от една страна, но от друга страна налагат много ограничения на интерфейса.
В резултат ние не правим функцията, която клиентът иска да получи, а такава, която е удобна за нас, защото вече имаме определени компоненти, от които можем да я направим.
Мисля, че си заслужава да обърнем внимание на това и да се замислим, дали в опитите си да улесним работата по дизайна разрешаваме наистина проблемите на клиента.
— Получава се удивително много теми, свързани с Quality Assurance. Има ли в Русия конференция, на която всички тях може да се обсъдят?
Анастасия: Има най-старата конференция по тестване, която тази година ще се проведе за 25-ти път и се нарича — Конференция по осигуряване на качеството SQA Days. Основно на нея се обсъждат инструменти и конкретни подходи за тестване за функционални тестировчици. Обикновено в докладите на SQA Days дълбочинно се разглеждат конкретни области в зоната на отговорност на самите тестировчици, но не комплексни мероприятия.
Това много помага да се разберат различните инструменти и подходи за тестване на бази данни, API и т.н. Но от една страна, не мотивира да се включват в създаването на по-качествени продукти не само тестировчиците. А от друга страна, тестировчиците не стават по-ангажирани в процеса, за да мислят за глобалната цел на продукта и бизнес съставката.
Ръководя голям отдел и провеждам много интервюта, които всъщност позволяват да добием представа за състоянието на индустрията като цяло. Обикновено нашите хора работят в enterprise и имат ясни зони на отговорност. Колегите, които работят в чуждестранни проекти, използват различни видове тестване: те могат да правят натоварващо тестване, тестване на производителността и дори понякога тестване на сигурността, защото наистина помагат на екипа да осигури качеството на продукта.
Бих искал и в Русия хората да започнат да се замислят, че индустрията не приключва с функционалното тестване.
— За това организираме новата конференция QualityConf, посветена на качеството като цялостна дисциплина. Разкажи повече за замисъла, каква е основната цел на конференцията?
Анастасия: Искаме да създадем общност от хора, заинтересовани да създават качествени продукти. Да предложим платформа, където те могат да дойдат, да слушат лекции и да си тръгнат след конференцията с конкретно разбиране какво трябва да променят при себе си за подобряване на качеството.
Често чувам запитвания от консултанти какво да правят, когато има проблеми с тестването и качеството. Когато започнеш да общуваш с екипите, виждаш, че проблемът не е в самите тестери, а в начина, по който е изграден процесът. Например, когато разработчиците смятат, че са отговорни само за написването на кода, тяхната отговорност приключва точно в момента, в който предадат задачата за тестване.
Не всички осъзнават, че лошо написаният некачествен код със слаба архитектура заплашва проекта с големи проблеми. Не мислят за разходите от грешки, за това, че бъгове, стигнали до продукция, могат да доведат до значителни разходи за компанията и екипа. Няма култура да се мисли за това. Искам на конференцията да започнем да я разпространяваме.
Разбирам, че това не е иновация. Едуард Деминг, автор на 14 постулата за качеството, говореше за цената на грешките още през миналия век. На основата на тази книга се базира Quality Assurance като дисциплина, но за съжаление, съвременната разработка забравя за това.
— А темите, свързани с тестването и инструментите, ще бъдат ли засегнати?
Анастасия: Допускам, че ще има лекции за инструменти. Има достатъчно универсални инструменти, с помощта на които компаниите и екипите могат да влияят на продукта.
Всички лекции глобално ще бъдат обединени от една обща мисия: да предадем на аудиторията, че с помощта на този подход, инструмент, метод, процес или вид тестване ние повлияхме на качеството на продукта и подобрихме живота на клиента.
Вярвам, че няма да имаме лекции за инструменти ради самите инструменти. Всички лекции, които ще бъдат включени в програмата, ще бъдат обединени от обща цел.
— Кому ще бъде интересно това, за което говориш, кого виждаш като гости на конференцията?
Анастасия: При нас ще има доклади за разработчици, които не са безразлични към съдбата на своя проект, продукт, система. Също така, това ще бъде интересно за тестировчици и, както ми се струва, особено за мениджъри. Под мениджъри имам предвид хора, които вземат решения и могат да влияят на съдбата и развитието на продукта, системата и екипа.
Това са хора, които си задават въпроса — как да повишат качеството на продукта, системата. На нашата конференция те ще научат за различни комплекси от мерки и ще могат да разберат какво не е наред и какво трябва да променят.
Мисля, че основният критерий е да разбереш, че с качеството нещо не е наред и да искаш да повлияеш на това. Вероятно, от първия път да достигнем до хора, които смятат, че и така става, няма да успеем.
— Как мислиш, индустрията като цяло узря ли за разговор не просто за тестване, а за култура на качеството?
Анастасия: Аз смятам, че е узряла. В момента много компании се отклоняват от традиционния Waterfall подход към Agile. Има ориентация към клиента, хората в екипите наистина започват да се замислят как да създадат качествен продукт. Даже в enterprise компании се наблюдава преориентация към повишаване на качеството.
Съдейки по количеството запитвания, които възникват в обществото, считам, че вече е време. Не съм сигурна, разбира се, че това ще бъде мащабна революция, но бих искала този обрат в съзнанието да се случи.
— Съгласихме се! Ще се стремим да внедряваме култура и да променяме съзнанието.
Конференция за качествена разработка на IT продукти ще се състои в Москва на 7 юни. Знаете ли, от какви етапи се състои качественият продукт, имаме случай на успешна борба с бъгове на продакшън, проверили сме популярни методики на практика — необходим е вашият опит. своите заявки до 1 май, а Програмният комитет ще помогне да насочи темата за общата последователност на конференцията.
Присъединявайте се към , в който обсъждаме въпросите за качеството и конференцията, абонирайте се за , за да сте в крак с новините по програмата.
Източник: habr.com
