User Acceptance Testing: як організувати процес менеджеру

Уявімо собі, що ви ведете проект по розробці програмного продукту і вже підійшли до етапу, коли мінімальний скоуп завершено, реліз-кандидат стабілізовано і настав час релізу. На цьому етапі необхідний додатковий крок, на якому ви ще раз перевірити систему разом з представниками бізнесу і вирішите, чи готова вона до выливке в продакшн. Цей етап називається User Acceptance Testing. Нижче поговоримо про те, для чого він потрібен, як до нього готуватися і що менеджер проекту повинен зробити для його проведення.

Відразу обмовлюся, що мова йде про застосування практики UAT в аутсорсингу. Кейс продуктової компанії тут не розглядається.

Для чого проводити UAT

Крок додаткової перевірки системи на такому пізньому етапі може здатися зайвим: швидше за все, ваш клієнт вже мав безліч можливостей подивитися на систему і «помацати» її в тестовій середовищі. Бачив демо і висловив фідбек, який ви разом з командою успішно реалізували в наступних спринтах. Більш того, ваша команда вже провела все необхідне тестування, включаючи регрессионное, і пройшла фазу стабілізації, вичистивши максимальна кількість дефектів.

Навіщо ж перевіряти систему ще раз?

Справа в тому, що під час регулярних демо після кожного спринту ваш клієнт бачив систему лише частково і, напевно, перевіряв її лише в розрізі конкретних функцій. Також цілком імовірно, що він не приділяв такої перевірки належної уваги, адже до релізу було ще далеко. На етапі UAT клієнт зможе оцінити систему в цілому і перевірити її в розрізі своїх бізнес-процесів, а не фіч.

Тут важливо розуміти слова «перевірка» і «тестування» у правильному контексті. Під час UAT клієнт не робить роботу інженера по якості, виловлюючи технічні дефекти коду. Він перевіряє, наскільки система, створена за його вимогам, відповідає бізнес-потребам. Наприклад, може виявитися, що клієнт забув описати якийсь важливий флоу або вказати на важливий параметр бізнес-процесу.

Таким чином, UAT — останній фільтр, який система повинна пройти перед тим, як стати доступною широкому загалу користувачів. За результатами цієї фази клієнт може прийняти два можливих рішення: виходити в продакшн або відкласти реліз, давши команді час на необхідні доопрацювання, якщо їх не вдалося виконати в рамках UAT.

Сценарії приймання

У попередньому розділі ми говорили, що під час UAT клієнт перевіряє систему в розрізі бізнес-процесів. Щоб зробити цей процес максимально продуктивним, а також якнайкраще підготуватись до нього, необхідно скласти та узгодити сценарії приймання.

Це опис послідовності дій користувача при виконанні того чи іншого бізнес-процесу. Сценарії приймання повинні включати як найбільш типові кейси, так і більш складні ситуації, які зустрічаються рідко, але їх система повинна також успішно обробляти.

Потрібні вони для того, щоб спланувати і впорядкувати роботу клієнта з приймання системи та формалізувати її. Клієнт пройдеться по всіх сценаріїв і по кожному з них дасть фідбек: все працює або є якісь зауваження. Більш того, при нестачі часу можна виділити найбільш пріоритетні сценарії і переглянути тільки їх — в більшості випадків цього буде достатньо.

Типовий сценарій приймання включає таку інформацію:

назва;
список кроків із зазначенням очікуваного результату і пріоритету (пріоритети кроків повинні бути обговорені заздалегідь);
колонки для надання фідбек: крок пройдений/не пройдено і поле для коментарів.

Нижче ви знайдете приклад одного з можливих шаблонів для сценарію приймання. Така таблиця використовується як на етапі підготовки та узгодження сценаріїв, так і на етапі проведення UAT — клієнт заповнює колонки для фідбек.

Scenario	#	Activity/Step	Description*	User result	Priority (High/Medium/Low)	Passing status (Pass/Fail/Pass with coments	Notes/feedback
Sales order Basic positive flow	1.1	Create Sales Order	e.g. «Use the general menu on the left» or link to the User manual	SO created, Invoice created		Pass with comment	Performance should be improved to 2 secs
	1.2	Add client to SO
	1.3	Generate and Send Offer
	1.4	Generate and Send Offer

Вхід у фазу UAT

Щоб продукт можна було віддати на приймання замовнику, реліз-кандидат повинен бути досить високої якості. Інакше клієнт замість перевірки бізнес-процесів буде займатися виявленням технічних дефектів (непрацююча валідація, з'їхала верстка, помилки 404 та інше), тобто фактично виконувати роботу QA-інженера.

Але «досить високу якість» — поняття абстрактне, його потрібно уточнити на етапі планування проекту або релізу і узгодити з клієнтом.

Як правило, параметри входу в UAT обумовлюють у вигляді кількості і рівня серйозності (severity) дефектів, які можуть залишатися в системі на момент початку UAT. Якщо дефектів більше, фазу UAT зрушують. Наприклад, критерій входу може виглядати так:

UAT може бути розпочато за умови, що після перевірки X% тест-кейсів в системі залишаються неусунення 0 дефектів з рівня blocker, до 3 дефектів з рівнем critical і не більше 10 дефектів з рівнем high.

Або інший приклад, з більш гнучкою формулюванням:

UAT може бути розпочато за умови, що після перевірки X% тест-кейсів в системі залишаються неусунення 0 дефектів з рівнем blocker та відсутні дефекти, блокуючі перевірку сценаріїв приймання з пріоритетом high і medium.

Рівні дефектів також потрібно обумовити, інакше вас чекають постійні суперечки про те, чи відноситься даний дефект до рівня normal або high. Значення рівнів можна придумати самостійно (можливо, у вас в команді або компанії вже усталений список). Але краще взяти щось стандартне (наприклад, ISTQB-стандарт c переліком рівнів дефектів можна знайти тут ).

Проведення приймання

Проведення приймання відбувається за заздалегідь визначеними сценаріями. По кожному кроку/сценарієм приймаюча сторона повинна проставити відмітку проходження (наприклад, pass/fail/pass with comments) і описати виявлену проблему. Зробити це можна прямо в таблиці зі сценаріями, або заводячи дефект в баг-трекінг систему (Jira, Redmine і так далі) і залишаючи номер дефекту в рядку з перевіряється кроком.

Для приймання має сенс підготувати для клієнта окрему тестову середу, наповнивши її даними, максимально наближеними до реальних. А якщо ви здійснюєте міграцію зі старої системи в нову, то краще наповнити тестову середу реальними даними клієнта, попередньо анонимизировав їх.

Часто буває корисно провести першу сесію UAT спільно з представником клієнта, в ідеалі онсайт. В цьому випадку процес зазвичай йде швидше, оскільки всі питання з'ясовуються в особистому спілкуванні. Надалі можна перейти на віддалений варіант спілкування і віддати частину приймання на самостійне виконання клієнту.

Важливе питання — хто саме повинен проводити приймання з боку клієнта. Від цього залежить ефективність процесу і цінність отриманих результатів. Поширений варіант, коли приймання виконує той самий чоловік, який працював з командою над вимогами, — продукт-оунер. В такому випадку приймання, швидше за все, пройде максимально швидко і з мінімальною кількістю зауважень. Зворотна сторона такого ефекту — продукт-оунер, не будучи кінцевим користувачем, може не знати про якихось важливих специфічних особливостей бізнес-процесу. Тоді проблеми все одно виявляться, але на більш пізній стадії, коли система почне реально працювати, а значить, ціна їх усунення зросте.

У зв'язку з цим більш кращий варіант, коли приймання проводять кінцеві користувачі, які попередньо пройшли необхідне навчання та інструктаж. Їм потрібно буде розповісти про систему, провести кілька демо і ознайомити з процесом. Продукт-оунер в такому разі стане точкою агрегації всіх запитів та зауважень користувачів. Він буде стежити за тим, щоб звіт про приймання був заповнений коректно, і приймати остаточне рішення про результати UAT.

У проведенні UAT, як і в будь-якому іншому процесі, вкрай важлива комунікація: чим швидше це відбувається, тим менше залишається «висячих» питань і тим вище шанси зробити все успішно. Дуже допомагають щоденні дзвінки, на яких ви разом з клієнтом проходите по виявлених зауважень і питань, з'ясовуєте, з'явилися в процесі нові вимоги або всі зауваження зводяться до усунення дефектів. Останнє особливо важливо, якщо ви працюєте з фіксованими строками і скоупом. Також ці дзвінки допомагають оперативно узгодити рівні виявлених дефектів і пріоритезувати їх усунення.

На будь-якому етапі проекту менеджеру необхідно тримати основних стейкхолдерів в курсі того, як просувається робота. І якщо на етапі активної розробки основний показник прогресу — це відсоток виконання скоупа, то на етапі UAT важливо моніторити такі метрики:

відсоток проходження за сценаріями приймання (план/факт);
відсоток прийнятих сценаріїв;
відсоток сценаріїв із зауваженнями;
відсоток відхилених сценаріїв;
кількість виявлених і усунених дефектів (за рівнями);
кількість запитів на зміну скоупа, виявлених за результатами UAT.

Вихід з UAT

Рідко коли приймання проходить абсолютно спокійно. Так чи інакше виявляються якісь нестиковки, виникають питання, заводяться дефекти. І хоча частина дефектів можна залишити на пострелизный період, деякі з них, швидше за все, виявляться важливими і терміновими і потребують усунення в рамках UAT.

Крім того, критерії входу в UAT, описані в одному з попередніх розділів, можуть бути досить м'якими. Це означає, що до моменту початку приймання в системі ще є достатня кількість дефектів. До кінця процесу їх повинно залишитися менше. Скільки саме і якого рівня — треба визначити критерії виходу з UAT .

Критерії виходу задають умови, при яких приймання може вважатися успішною, а система — допущена до релізу. Як і в критеріях входу, тут мають значення такі характеристики:

кількість і рівень дефектів у системі;
допустима кількість і пріоритет сценаріїв, які мають статус failed.

Наприклад, критерій виходу може звучати так:

Система вважається готової до релізу, якщо:

всі сценарії приймання, мають пріоритет high, в статусі pass;
більше 80% сценаріїв з пріоритетом medium і low мають статус pass;
залишаються неусунення 0 дефектів рівня blocker і high і не більше 10 дефектів рівня normal.

Конкретні значення, природно, повинні бути узгоджені окремо в кожному конкретному випадку. Для мобільної гри критерії можуть бути м'якими (тут більш важлива швидкість виходу на ринок), а медична система повинна відповідати дуже високим стандартам якості.

У будь-якому випадку остаточне рішення про вихід в продакшн приймає клієнт. Ваше завдання — дати рекомендації на підставі узгоджених раніше критеріїв і надати клієнтові всю необхідну інформацію для прийняття рішення.

При виході з UAT є два варіанти вирішення: виходити в продакшн або відкласти реліз для усунення дефектів і виконання необхідних доопрацювань.

При відкладанні релізу після внесення необхідних змін у систему приймання, як правило, не повторюється в повному обсязі — перевіряють тільки ті сценарії, які були внесені зміни. Після цього звичайно випливає рішення про вихід в продакшн, хоча в деяких випадках клієнт може захотіти вийти на друге коло змін. Тут важливо не захоплюватися нескінченної «поліруванням» продукту, адже можна втратити дорогоцінний час виходу на ринок. Але остаточне рішення залишається за клієнтом.

Приклади

На закінчення наведу кілька прикладів проектів з моєї особистої практики і практики колег.

Кейс 1 — система для планування подорожей онлайн

Сценарії приймання були відсутні, за винятком однієї функціональної області, пов'язаної з платежами. При цьому вона проводилася по групах функцій (эпикам). Я б не рекомендував так робити (і не робив надалі на своїх проектах). Справа в тому, що такий підхід не дозволяє перевірити систему як ціле, а обмежується лише повторною перевіркою функцій.

Критерії приймання для кожного епіка звучали так:

відсутність дефектів рівня critical/blocker/major;
дефекти більш низьких рівнів можуть бути присутніми, якщо вони в сукупності не блокують користувача в проходженні за основним флоу.

При цьому ці критерії фактично були як для входу, так і для виходу з UAT: спочатку епік перевіряла команда вендора, потім (по тим же критеріям) — команда клієнта.

Як це часто буває, основною складністю при прийманні було довести клієнтові, що частина «дефектів» насправді це зміни до скоупу. З цією метою до початку роботи над релізом був сформований бейзлайн скоупа і досягнута домовленість з клієнтом, що все, що не описано явно не входить в скоуп релізу. Також команди вендора і клієнта щодня зізвонювалися для обговорення результатів та класифікації знайдених дефектів: якісь з них зізнавалися дефектами, деякі — змінами до скоупу. За останніми клієнт вирішував — зрушити реліз або відкласти зміни.

Кейс 2 — зв'язка декількох систем

Тут кілька команд паралельно розробляли кілька систем, які обслуговують суміжні бізнес-процеси. Релізи у частині систем були суміщені, у частини — рознесені в часі. Приймання при цьому проводилася так:

Писала сценарії команда вендора (конкретніше — бізнес-аналітики), їх стверджував клієнт.
На двох найбільш критичних системах були присутні критерії входу/виходу з UAT, сформульовані в кількості дефектів різного рівня + в пріоритетах сценаріїв приймання.
На тих же двох системах у клієнта були чіткі часові рамки на здійснення приймання (робота йшла з фіксацією термінів релізу).

У контексті спільної розробки декількох систем дуже важливо упевнитися в тому, що вони коректно працюють спільно . Для цього ми передбачили не тільки «внутрішньосистемні» сценарії, але і такі, коли флоу починається в одній системі, проходить через другу і закінчується в третій. Зокрема, так тестувалася інтеграція з legacy-системою клієнта.

Навіть таке покриття не страхує вас від труднощів на 100%. У нашому випадку неприємним сюрпризом стало раптове оновлення прошивки на POS-терміналах якраз в останній день приймання. Так що версії ПЗ і апаратного забезпечення теж варто включати в опис сценаріїв.

Приймання починалася з спільних сесій з клієнтом, потім клієнт продовжив вже самостійно. Це дозволило суттєво прискорити процес. Як і в попередньому кейсі, велася практика щоденних дзвінків для обговорення результатів приймання та класифікації дефектів.

Кейс 3 — Data Science проект

Тут все було дещо складніше, оскільки критерії приймання в такого роду проектах важко сформулювати так само однозначно, як в проектах традиційної розробки. Команда пройшла шлях від стану, коли клієнт стверджував: «Система повинна працювати на будь-яких наборах даних», до більш прагматичного підходу, коли визначено кінцеве безліч форматів вхідних даних, на яких система повинна працювати коректно.

Фактично проводилося два типи приймання: приймання функціональності інтерфейсу за традиційною схемою + приймання якості алгоритму обробки даних.

Спочатку для релізу були визначені критерії успішності — типові приклади вхідних даних, які система повинна була успішно обробити.

Надалі приймання алгоритму проводилася на підставі зазначених прикладів.

Ще раз коротко про головне

UAT проводиться для перевірки системи в розрізі бізнес-процесів, а не окремих функцій. При цьому система перевіряється як цілісний механізм. Це дозволяє переконатися в тому, що її можна починати експлуатувати в реальному житті.
Для входу та виходу з UAT повинні бути сформульовані критерії — найчастіше у вигляді кількості/рівня дефектів.
UAT краще всього проводити за попередньо узгодженим і приоритизированным сценаріями приймання.
В ході UAT важлива комунікація: постійні мітинги для обговорення прогресу + структурований репортинг.
За результатами UAT клієнт може прийняти рішення про вихід в продакшн або про перенесення релізу.

Опубліковано: 12/05/20 @ 10:00
Розділ Різне

SEO Блог