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