User Acceptance Testing (UAT) – приймальне тестування та його цілі

Як проходить тестування ПЗ

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

• Планування
• Аналіз поставлених вимог
• Дизайн і, власне сама розробка проекту
• Імплементація коду та отримання кінцевого продукту
• Тестування
• Оцінка
• Реліз
• Забезпечення підтримки

Етап тестування – обов’язковий етап життєвого циклу ПЗ. Це дуже важливий процес роботи над проектом, на якому визначається, що зроблено правильно і добре, а що – ні. В інтернеті можна зустріти визначення терміну «тестування» як процес пошуку помилок. Насправді це твердження правильне лише частково. Одна з аксіом software development говорить про те, що знайти всі баги неможливо. І, якщо в результаті детального тестування не було виявлено жодної помилки, це ще не означає, що їх немає.

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

Поняття якості – річ звісно суб’єктивна. Проте, у кожному проекті ми маємо якесь очікування результату. З початку роботи над продуктом, product owner, який вигадав якусь ідею, має деякий набір уявлень про те, як має виглядати кінцевий проект. Він прописав вимоги, з ним попрацювали аналітики, склали для розробників списки вимог. Завдання тестувальника – переконатися, що якість продукту відповідає очікуванням замовника. Не суб’єктивним очікуванням самого тестувальника, не очікуванням проектного менеджера, а саме очікуванням того, хто є первісним автором ідеї.

Що таке User Acceptance Testing?(приймальне тестування)

Давайте трохи розберемося як організовано тестування ПЗ загалом. У процесі тестування розрізняють дві області. За першу частину, на позиції QC (Quality Control) відповідає test engineer – після тестів він виконує верифікацію щодо виправлених помилок (наприклад, попливла верстка, не працюють кнопки, некоректно обробляються посилання тощо). За другу область відповідальний QA (Quality Assurance) – він забезпечує якість вихідного продукту на прийнятному рівні. Він входить у роботу ще на стадії аналізу та опрацюванні архітектури. Покладаючись на свій досвід і чуття, він ще на ранніх стадіях пропонує внести правки до документації та змінити список вимог, завдяки чому мінімізуються ризики погіршення якості продукту. Також він передбачає вузькі місця в архітектурі та готує набір тестів, що вже на початку роботи над продуктом дозволять виявити деякі дефекти. QA значною мірою економить витрати на весь процес розробки, оскільки виправлення недоліків, пропущених на початковому етапі, згодом серйозно позначається на кошторисі всього проекту.

До речі, підбираючи кандидата на роботу, HR зазвичай не робить відмінностей і називає посаду тестувальника абияк – QA-аналітик, QA-інженер тощо. Тут слід розуміти, що посаду визначає замовник аутсорсингової послуги, який хоче отримати співробітника з якомога ширшим спектром скілів. Але робота Quality Assurance порівняно з Quality Control набагато об’ємніша і складніша. У першому випадку фахівець просто виконує тести і складає баг-репорти, у другому – людина повинна вибудувати і забезпечити контроль за якістю всього проекту.

Міжнародною кваліфікаційною комісією з тестування програмного забезпечення ISTQB розрізняють такі рівні тестування:

• Модульне випробування. Відповідальність за юніт-тести зазвичай лежить переважно на самих девелоперах, компетенція яких дозволяє їм легко орієнтуватися в коді. Припустимо, ваш проект – інтернет-магазин, що складається з великої кількості веб-додатків та окремих модулів (блок реєстрації, модуль авторизації, пошук, фільтри пошуку та ін.). Тестування на рівні окремо взятої опції – це і є модульне тестування. Unit-тести виконуються лише на рівні коду. Наприклад, якщо у калькуляторі виконати перевірку додавання 2 та 2, а у вікні бачимо «5» це ще не свідчить, що функція Sum(a,b) працює некоректно. Можливо, помилка криється в іншому місці і калькулятор висвічуватиме п’ять що б ми не вводили. Тому тестами ми перевіряємо роботу лише цієї функції умовою if Sum(2, 2) = 4 then...

• Інтеграційний рівень тестування. Він означає тестування кількох взаємодіючих модулів системи щодо того, як вони передають між собою дані та виконують операції при взаємодії один з одним.
• Системний рівень тестування – тестування всієї системи в цілому, перевірка того, як вона працює. Цей рівень тестування враховує оточення – на якій платформі працює програмне забезпечення, на якому девайсі відбувається його запуск, який браузер використовувався, яка була локалізація і т.д. Усі тести проганяються з урахуванням різних умов.
• Приймальне тестування – це формальний рівень тестування, який задіюється тоді, коли продукт досягає необхідного рівня якості. Він визначає, чи збігається результат з очікуваннями замовника. Для цього застосовується набір типових тестових випадків та сценаріїв, розроблених спеціально під даний проект.

Цілі та переваги приймального тестування

На перший погляд, приймальне тестування на останньому рівні може здатися надлишковим. Якщо орієнтуватися на замовника, то він, напевно, вже не раз «мацав» сирий (ну, або й не дуже сирий) продукт, залишав свої коментарі (фідбек) з приводу його роботи. Однак тут слід розрізняти «перевірку» та «тестування». Рівень приймального тестування призначений не для того, щоб виявити помилки, а щоб оцінити, наскільки продукт готовий до продакшену та чи відповідає він бізнес-вимогам замовника. UAT – це не функціональне тестування, воно не виявляє збої в роботі, а дає оцінку продукту загалом, виявляючи наскільки він зручний та придатний для використання.

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

Документи, необхідні для приймального тестування

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

Приймальне тестування вимагає кілька робочих документів:

• План прийомних випробувань – тобто список тестів, що проводяться. Він складається ще на етапі розробки для формування архітектури проекту
• Формат UAT – опис з вимогами тестування, предмет тестування та сценарії тестування з урахуванням вимог
• Реєстр коментарів до процесу тестування
• Протокол UAT

Існують різні підходи до приймального тестування. Чек-лист з найчастішими формами перевірки проекту виглядають так:

1. Альфа-бета тестування – залучення групи реальних користувачів.
2. Контрактне тестування – перевірка відповідності продукту ТЗ.
3. Операційне тестування – варіант тестування, у якому аналізуються процеси, що необхідні для функціонування продукту. Це можуть бути, наприклад, системи захисту, різні послуги для резервного копіювання та відновлення інформації та ін.
4. Законодавче тестування – визначає, наскільки програмний продукт відповідає чинному законодавству. Особлива увага приділяється, якщо проект має відношення до фінансової діяльності чи сфери охорони здоров’я.

Інструменти UAT, приклади тестування

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

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

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

Скрипт для acceptance testing в Watir може виглядати, наприклад, так:

# Приклад невеликого скрипту для перевірки послідовності дій

 require 'watir'                          # підключаемо інструмент Watir

 testing _site = 'http://www.some_adress.com'      # визначаємо змінну
 ie = Watir::IE.new                       # запускаємо браузер Internet Explorer

 ie.goto(testing _site)                   # переходим за посиланням

 ie.text_field(:name, "search").set("Picasso") #у текстове поле з ім'ям "search" розміщуємо слово "Picasso"

 ie.button(:name, "Knopka").click           # натискання на кнопку з ім'ям "Knopka"

 if ie.text.include?("Programming Ruby")  # опис умови тесту

   puts "Test Passed. Found the test string: 'Programming Ruby'." # висновок щодо успішного проходження
 else

   puts "Test Failed! Could not find: 'Programming Ruby'" #тест не пройдено

 end

Висновок

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