Що таке UAT

Для команд розробки UAT (User Acceptance Testing) не дуже часто є частиною їх практики – він може проходити поза лаштунками первинного виробництва, його можуть проводити якось-такось. А ось коли замовник просить вас підготувати Стратегію тестування та визначити як ви будете проводити та готуватись до UAT – ви починаєте скажено гуглити what is faking UAT. Це нормально. Є кілька точок зору на UAT – пропоную варіант.

Зрозуміймо нащо проводити UAT. Замовник бажає визначитись чи дійсно замовлене програмне забезпечення. А як замовник це визначить? З точки зору замовника програмне забезпечення має забезпечувати роботу основних бізнес-сценаріїв від початку до кінця. Тобто ми маємо визначити всі наскрізні бізнес-сценарії, відокремити всі гілки прийняття рішень та таким чином отримаємо план тестування та виконати весь бізнес сценарій (процес) від початку до кінця.

До планування UAT таким чином можна додати:

  • Перелік наскрізних бізнес-сценаріїв, відокремити важливі ланцюги прийняття рішень або опцій
  • Визначити які нефункціональні вимоги будуть продемонстровані протягом UAT по бізнес сценаріям, а які вимагають окремого UAT
  • Визначити перелік конфігурацій кінцевого обладнання для користувачів
  • Визначити базові дані – що має бути в системі на початку UAT
  • Організувати план тестування UAT – це план у якому Test Suites відіграють роль бізнес сценаріїв, а Test Cases можуть використовуватись як кроки тестування. Або готувати окремі Test Cases зі спрощеним визначенням UAT сценарію – це залежить від ресурсів тестування та вимог замовника
  • Визначити порядок проведення UAT – хто що робить
  • Забезпечити проведення UAT – організувати необхідне для виконання обладнання, середовища, необхідні ліцензії, налаштувати ALM тощо

Чим відрізняється UAT від звичайного тестування:

  • Під час UAT ми не заглиблюємось в безліч опцій, обираємо основні варіанти. Якщо умовою UAT є демонстрація стійкості до варіантів вводу – тоді ми заглиблюємось.
  • Ми фокусуємось на загальному процесі, а не на окремій операції
  • Ми мислимо профілями зацікавлених сторін та користувачів, наші дії мають бути близькими до реальності. Наприклад як ви плануєте тестувати форму скарги – у спокійному стані або у стані люті на вулиці з підмороженими пальцями? Так, важливо максимально наблизитись до реального стану речей та продемонструвати що воно _реально_ працює
  • в _реальних_ умовах. А це також погане освітлення, малий заряд акумулятора, поганий зв’язок, старий телефон тощо.

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

Залишити відповідь