Меню

Що таке тестування на прийнятність користувача (UAT): Повне керівництво

what is user acceptance testing

Спробуйте Наш Інструмент Для Усунення Проблем

Дізнайтеся, що таке тестування прийняття користувача (UAT), а також його визначення, типи, кроки та приклади:

Моє правило номер один при спробі зрозуміти нову концепцію полягає в тому, що: назва завжди буде актуальною і в основному буквальним значенням (в технічному контексті).

Дізнавшись, що це таке, дасть початкове розуміння цього та допоможе мені розпочати.

java передає масив методу за посиланням

=> Клацніть тут, щоб отримати повну серію підручників з плану тестування

Тестування прийняття користувача (UAT)

Давайте випробуємо цю концепцію.

=> Прочитайте всі підручники у нашій серії приймальних випробувань.

Що ви дізнаєтесь:

Що таке тестування на прийнятність користувача?

Ми знаємо, що таке тестування, прийняття означає схвалення або домовленість. Користувачем у контексті програмного продукту є або споживач програмного забезпечення, або особа, яка вимагала його побудови для нього (клієнта).

Отже, дотримуючись мого правила - визначення буде таким:

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

Основна мета цього тестування - перевірити програмне забезпечення на відповідність вимогам бізнесу. Ця перевірка проводиться кінцевими користувачами, які знайомі з бізнес-вимогами.

UAT, альфа та бета тестування є різними видами приймально-здавальних випробувань.

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

Коли це виконується?

Це, як правило, останній крок до того, як товар надійде в дію або до того, як буде прийнята доставка товару. Це виконується після ретельного тестування самого продукту (тобто після тестування системи ).

коли виконується UAT

Хто виконує UAT?

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

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

Необхідність тестування на прийнятність користувача

Розробники та тестувальники функцій - це технічні люди, які перевіряють програмне забезпечення на відповідність функціональні характеристики . Вони інтерпретують вимоги відповідно до своїх знань та розробляють / перевіряють програмне забезпечення (тут важливість знань доменів).

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

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

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

Чи справді необхідна UAT?

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

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

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

Процес перевірки прийнятності користувача

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

Нижче наведено передумови до початку етапу планування:

# 1) Зберіть ключові критерії прийнятності

Простіше кажучи, Критерії прийнятності - це перелік речей, які потрібно оцінити перед прийняттям товару.

Вони можуть бути двох типів:

(i) Функціональність додатків або бізнес

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

(ii) Договірні - Ми не збираємося цим займатись, і участь команди з контролю якості у всьому цьому майже ніщо. Первинний контракт, який складається до того, як починається SDLC, переглядається і досягається домовленість про те, чи всі аспекти контракту були надані чи ні.

Ми зупинимось лише на функціональності програми.

# 2) Визначте сферу участі у забезпеченні якості.

Роль команди з контролю якості є однією з наступних:

(i) Відсутність участі - Це дуже рідко.

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

(iii) Виконати UAT та представити результати - Якщо це так, користувачі вказуватимуть області AUT, які вони хочуть оцінити, а саме оцінювання виконує команда QA. Після завершення результати представляються клієнтам / користувачам, і вони приймають рішення про те, чи є результати, якими вони володіють, достатніми чи ні, і відповідно до їхніх очікувань, щоб прийняти AUT. Рішення команди QA ніколи не приймається.

Залежно від конкретного випадку, ми вирішуємо, який підхід є найкращим.

Основні цілі та очікування:

Цілі та очікування UAT

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

Основні напрямки діяльності кожного етапу UAT визначені нижче:

Основні напрямки діяльності кожної фази UAT

Управління UAT

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

** Зверніть увагу, що це лише вказівка. Це може бути змінено залежно від потреб та вимог проекту.

Управління UAT

Планування випробувань UAT

Процес майже такий самий, як і з регулярний план тестування у фазі системи.

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

План приймальних випробувань користувачів

(Це те саме, що ви також знайдете на нашому сайті для навчальної серії QA).

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

План випробувань UAT

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

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

=> Ось зразок документа щодо плану прийняття користувачем

Дизайн приймальних випробувань користувачів

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

(Це уривки з CSTE CBOK . Це одне з найкращих посилань щодо цього тестування.)

Шаблон тестування прийняття користувача:

Шаблони UAT

грати вау безкоштовно приватний сервер - -

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

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

Виконання тесту

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

Або у випадку, якщо команда з контролю якості виконує тести, ми запускаємо тестові кейси на AUT.

Як тільки всі тести будуть запущені і результати будуть в наявності, Рішення про прийняття зроблено. Це також називається Рішення Go / No-Go . Якщо користувачі задоволені, це 'Поїздка', або ж це 'Заборона'.

Досягнення рішення про прийняття, як правило, закінчується цим етапом.

Інструменти та методології

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

Інструменти:

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

Подібно до тестування системи, користувачі також можуть використовувати інструменти управління тестами та управління дефектами, такі як QC, JIRA тощо. Ці інструменти можна налаштувати для накопичення даних для фази прийняття користувача.

Методології:

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

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

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

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

Методологія тестування натовпу виявляється більш ефективною, оскільки пульс замовника по всьому світу можна легко зрозуміти.

UAT в гнучкому середовищі

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

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

Більше того, до завершення спринту планується запланувати етап UAT, де бізнес-користувачі проведуть свою перевірку.

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

Команда UAT - Ролі та обов'язки

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

РоліОбов'язкиРезультати
Керівник бізнес-програми• Створення та підтримка плану виконання програми
• Переглянути та затвердити стратегію та план випробувань UAT
• Забезпечити успішне завершення програми за графіком та бюджетом
• Зв’яжіться з менеджером ІТ-програми та контролюйте хід програми
• Тісно співпрацюйте з командою з ділових операцій та готуйте їх до першого дня
• Документ про випуск бізнес-вимог
• Перегляньте зміст курсу електронного навчання
• Звіт про хід програми
• Щотижневий звіт про стан
Менеджер тестів UAT• Стратегія UAT на Криті
• Забезпечити ефективну співпрацю між ІТ та бізнесом BA та PMO
• Брати участь у настановах щодо покрокових вимог
• Переглянути оцінку зусиль, план випробувань
• Забезпечити простежуваність вимог
• Заохочуйте збір метрик для кількісної оцінки переваг, отриманих від оновленої методології тестування, інструментів та використання середовища
• Стратегія майстер-тестування
• Переглянути та затвердити сценарії тестування
• Перегляд і затвердження тестових випадків
• Перегляд і затвердження матриці простежуваності вимог
• Щотижневий звіт про стан
Тест-керівник та команда UAT• Перевірити та підтвердити ділові вимоги щодо бізнес-процесів
• Оцінка для UAT
• Створення та виконання плану тестування UAT
• Візьміть участь у сесії JAD з вимогою
• Підготовка сценаріїв тестування, тестових кейсів та даних тестів на основі бізнес-процесів
• Зберігати відстежуваність
• Виконувати тестові кейси та готувати журнали тестів
• Повідомте про дефекти в інструменті управління тестами та керуйте ними протягом усього їх життєвого циклу
• Виготовити звіт про закінчення випробувань UAT
• Забезпечити підтримку готовності до бізнесу та підтвердження в реальному часі
• Тестовий журнал
• Щотижневий звіт про стан
• Звіт про дефекти
• Метрики виконання тесту
• Підсумковий звіт про випробування
• Архівні багаторазові тестові артефакти

7 викликів UAT та плану пом'якшення наслідків

Тестування UAT

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

# 1) Процес налаштування та розгортання середовища:

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

Для цього тесту слід створити окреме виробниче середовище.

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

Тим часом час, необхідний для відстеження проблем із неправильною версією програмного забезпечення, високий.

# 2) Планування випробувань:

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

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

Це тестування проводиться в кінці циклу тестування. Очевидно, що це найкритичніший період для випуску програмного забезпечення. Затримка на будь-якому з попередніх етапів розробки та тестування поглине час UAT.

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

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

# 3) Обробка нових бізнес-вимог як інцидентів / дефектів:

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

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

# 4) Некваліфіковані тестери або тестери без знання бізнесу:

Коли постійної команди немає, компанія відбирає співробітників UAT з різних внутрішніх підрозділів.

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

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

# 5) Неправильний канал зв'язку:

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

Правильне планування та ефективне спілкування мають вирішальне значення для ефективної співпраці команди. Команди проектів повинні використовувати веб-інструмент для реєстрації дефектів та питань. Це допоможе рівномірно розподілити навантаження та уникнути повідомлення про повторювані проблеми.

# 6) Попросити команду функціонального тестування виконати це тестування:

Існує не гірша ситуація, ніж попросити команду функціональних тестів виконати UAT.

найкраще програмне забезпечення для Windows 10

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

Рішенням цього є призначення цього тестування спеціалізованим та кваліфікованим тестувальникам, які мають бізнес-знання.

# 7) Гра у звинувачення

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

Дуже важко впоратися з такими ситуаціями. Однак побудова позитивних стосунків з бізнес-командою, безумовно, допоможе уникнути гри у звинуваченні.

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

Системне тестування проти тестування прийняття користувачами

Залучення групи тестування починається досить рано в проекті вже з фази аналізу вимог.

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

Незважаючи на те, що ми бачимо різницю в SIT та UAT, важливо використовувати синергію, але все ж зберігати незалежність між обома фазами, що дозволить швидше вийти на ринок.

Відмінності та синергія UAT

Висновок

# 1) UAT - це не сторінки, поля чи кнопки. Основний припущення ще до того, як цей тест розпочнеться, це те, що всі основні речі перевірені і працюють нормально. Не дай Бог, користувачі вважають помилку настільки основною, як це - це дуже погана новина для команди QA. :(

# два) Це тестування стосується організації, яка є основним елементом у бізнесі.

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

Інший Приклад, якщо сайт - це сайт автосалону, тоді основна увага приділяється “машині та її продажам”, а не справді сайту. Отже, основний бізнес - це те, що перевіряється та перевіряється, і хто краще це робити, ніж власники бізнесу. Ось чому це тестування має найбільший сенс, коли клієнт задіяний у значній мірі.

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

Рішення буде:

  • Натисніть дату запуску, спочатку виправте проблему, а потім рухайтесь далі.
  • Залиште помилку як є.
  • Розгляньте це як частину запиту на зміни для майбутніх випусків.

# 4) UAT класифікується як альфа- та бета-тестування, але ця класифікація не настільки важлива в контексті типових проектів розробки програмного забезпечення в галузі послуг.

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

# 5) Більшість часу в рамках звичайного проекту з розробки програмного забезпечення UAT виконується в QA середовище якщо відсутня інсценізація або середовище UAT.

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

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

Яким був ваш досвід UAT? Ви були в режимі очікування чи тестували для своїх користувачів? Чи знайшли користувачі якісь проблеми? Якщо так, то як ти з ними справився?

=> Також читайте ВСІ підручники з цієї серії тут

=> Завітайте сюди, щоб отримати повну серію навчальних програм з плану випробувань

Рекомендована література

^