П’ять способів врятувати User Acceptance Testing (UAT) на вашому проєкті

User Acceptance Testing (UAT) — або так зване «приймальне тестування» — важливий етап наприкінці процесу розробки. За умови правильного проведення він може значно зменшити кількість потенційних помилок у продакшені. Якщо ви працюєте на досить складному проєкті, скоріш за все до UAT залучені представники клієнта та/або люди з бізнесу замовника. На великих проєктах User Acceptance Testing більш структурований, а от на маленьких його може зовсім не бути, або він буде проходити неформально.

Мене звати Юрій Бабай, я співпрацюю з ЕРАМ у ролі керівника команди тестувальників. У цьому матеріалі поділюсь своїм досвідом, який допоможе оминути розповсюджені помилки та провести User Acceptance Testing якісно.

Перш за все зауважу, що в ідеалі User Acceptance Testing має бути запланованим на початку процесу розробки і включеним у проєктний план. В класичному варіанті UAT починається після того, як імплементований весь функціонал продукту. Але фактично це тестування може відбуватись заздалегідь — і в цьому випадку дуже важливо коректно визначати його межі. Але про це — трохи згодом.

До процесу User Acceptance Testing варто готуватись заздалегідь як команді розробки, так і замовникам. Необхідно бути впевненими, що у всіх залучених осіб є доступ до тестового оточення, дизайну, тестових даних тощо. Дуже важливо також, щоб представники клієнта знали початкові вимоги до продукту: тоді вони будуть репортити саме дефекти, а не генерувати безліч побажань до того, як має працювати продукт.

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

Також на етапі підготовки треба визначити критерії успішного і неуспішного User Acceptance Testing. Це може бути наявність дефектів, кількість критичних дефектів відносного їхньої загальної кількості, скільки провалених тест-кейсів тощо. Якщо не проговорити критерії одразу на початку, на фазі UAT замовник може просити виправити все, що вважатиме дефектами.

Отже, припустимо, що стадія UAT відбувається не найкращим чином, ви відчуваєте, що атмосфера стає напруженою. Розберімося, що могло піти не так, і як виправити ситуацію.

Кейс 1. Стартували UAT раніше оптимального терміну

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

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

Насправді щоб розпочинати User Acceptance Testing, необхідно розуміти готовність продукту до цієї активності. Звісно, що раніше замовник бачить продукт — то оперативнішим буде зворотній зв’язок і більше часу залишиться для змін. Але очікуваннями UAT-тестувальників треба чітко керувати і нагадувати: якщо на цьому етапі щось працює некоректно або певна частина продукту недоступна — це нормальний процес, продукт буде покращено згодом.

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

Кейс 2. До UAT фактично не готувались

Перш за все — у всіх учасників User Acceptance Testing має бути однаковий доступ до вимог та спільний «словник»: що вони вважають дефектом, а що — запитом на додаткову розробку або change request, який виник під час UAT. Якщо упустити з поля зору цей момент, обсяг роботи для команди може почати некеровано рости: інженери інвестуватимуть свій час у виправлення помилок, які фактично будуть новими вимогами.

Для керівника тестувань на проєкті підготовка UAT — один з процесів, в який він має бути безпосередньо залучений. Тест-лід повинен впевнитись, що існує список людей, які займатимуться User Acceptance Testing, у них є всі необхідні доступи до оточення, вимог, дизайнів тощо, визначені контактні персони на боці команди розробки та є чітке розуміння, де різниця між дефектом і change request у випадку цього конкретного проєкту. Все це тест-лід має проговорити, а потім закріпити у листі до команди UAT.

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

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

Загалом, підготовка — це вкрай важливо для UAT.

Кейс 3. Невірно добирали UAT команду

Щоб процес User Acceptance Testing проходив коректно, у команді UAT тестувальників мають бути ті, хто реально працюватиме з продуктом у майбутньому. Ці люди розуміють, як повинен працювати продукт та можуть дати корисний зворотній зв`язок як його покращити.

А от залучати цілковитих новачків у обраній доменній області — небезпечно. Вони скоріше будуть відволікати базовими, тривіальними запитаннями. Адже реальні користувачі скоріше за все знайомі з доменом.

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

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

Кейс 4. Неякісно написані тестові сценарії

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

Необхідно пам’ятати, що User Acceptance Testing — це не про запуск вже готових тест-кейсів. Воно має допомогти виявити, чого продукту бракує, а що є зайвим. Саме тому важливо приділити увагу покриттю сценаріїв. Інколи до уваги беруть лише критичні фічі застосунку, а менш важливі випускають, проте під час реального запуску мінорні недоліки виходять на передній план і це псує загальне враження від продукту.

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

Запитайте у команди User Acceptance Testing, чи будуть вони використовувати сценарії від команди розробників або напишуть власні. Домовтесь про рев’ю та обмін фідбеком і не забувайте контролювати покриття сценаріїв. Воно має поширюватись на весь функціонал.

Кейс 5. Недоліки комунікації

Чим швидша та якісніша комунікація під час User Acceptance Testing — тим краще. Вам необхідно давати зворотній зв’язок оперативно, щоб тестувальники з боку замовника були в контексті. Це не лише прискорить процес, але й позитивно вплине на рівень довіри до вас. Створіть чат у зручному для обох сторін месенджері, заохочуйте запитання. Це може вберегти від репортинга дефектів, які насправді є фічами.

Також не варто нехтувати регулярними дзвінками, щоб обговорювати глобальні питання та оптимізувати процес User Acceptance Testing. Долучіть до дзвінків представника вашого менеджменту, людину з команди розробки і тестувальників з боку замовника. Тоді дискусії будуть продуктивними та корисними. Якщо питань для обговорення небагато — буде достатньо 1-2 зустрічей на тиждень. В іншому випадку плануйте їх щодня, щоб оперативно вирішувати різні ситуації та усувати перешкоди.

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

P.S. UAT метрики

Існує дуже багато метрик, які можна застосувати, щоб виміряти ефективність User acceptance testing. В цій статті хочу поділитися ТОП 3, які стали в пригоді особисто мені:

• Кількість підтверджених/ не підтверджених UAT дефектів. Одна з найважливіших метрик. Вона показує, що було пропущено на попередніх етапах тестування та дозволяє перелаштувати тестовий процес. Якщо більшість дефектів не підтверджується, то виникає питання до команди UAT та їхньої обізнаності в плані вимог і навичок користування системою.
• Пріоритет/ серйозність підтверджених дефектів. Маючи ці дані, можна показати замовнику рівень якості продукту. Але подбайте, щоб у переліку не було критичних та блокувальних дефектів.
• Причина дефекту. Як правило, фіксований список, з якого можна обрати, що саме спричинило дефект. Це може бути баг у коді, тестові дані, конфігурація тощо. Ця метрика покаже, звідки «прийшли» дефекти.

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

Насамкінець — не варто плутати цю активність з End To End тестуванням: UAT, на мою думку, має їй передувати.