Техніки тестування засновані на співпраці (версія 4.0)
Кожен із методів тестування має певну мету щодо виявлення дефектів. З іншого боку, підходи, засновані на співпраці, зосереджуються також на уникненні дефектів шляхом співпраці та спілкування.
Спільне написання історії користувача (версія 4.0)
Історія користувача представляє функцію, яка буде цінною для користувача або покупця системи чи програмного забезпечення. Історії користувачів мають три важливі аспекти (Jeffries 2000), які разом називаються «3 C»:
- Картка (Card) – засіб опису історії користувача (наприклад, індексна картка, запис на електронній дошці)
- Розмова (Conversation) – пояснює, як використовуватиметься програмне забезпечення (може бути задокументовано або усно)
- Підтвердження (Confirmation) – критерії прийняття
Найпоширеніший формат історії користувача: «Як [роль], я хочу [досягнути мети], щоб я міг [результивна бізнес-цінність ролі]», а потім критерії прийняття.
Спільне авторство історії користувача може використовувати такі методи, як «мозковий штурм» і розумового пов’язування (mind mapping). Співпраця дозволяє команді отримати спільне бачення того, що має бути надано, беручи до уваги три точки зору: бізнес, розробка та тестування.
Хороші історії користувачів мають бути: незалежними, такими, що підлягають обговоренню, цінними, такими, що підлягають оцінці, невеликими та перевіреними (INVEST). Якщо зацікавлена сторона не знає, як перевірити історію користувача, це може означати, що історія користувача недостатньо зрозуміла, або що вона не відображає чогось цінного для них, або що зацікавленій стороні просто потрібна допомога в тестуванні (Wake 2003).
Приймальні критерії (версія 4.0)
Приймальні критерії для історії користувача — це умови, яким має відповідати реалізація історії користувача, щоб бути прийнятою зацікавленими сторонами. З цієї точки зору, приймальні критерії можна розглядати як умови тестування, які повинні виконуватися тестами. Критерії прийняття зазвичай є результатом спілкування.
Критерії прийнятності використовуються для:
- Визначення обсягу історії користувача
- Досягнення консенсусу серед зацікавлених сторін
- Опису як позитивних, так і негативних сценаріїв
- Слугують як основа для перевірки прийнятності історії користувача
- Дозволяють точне планування та оцінку
Є кілька способів написати критерії прийняття для історії користувача. Два найпоширеніші формати:
- Орієнтований на сценарій (наприклад, формат Given/When/Then, що використовується в BDD)
- Орієнтований на правила (наприклад, список перевірки маркерів або таблична форма відображення введення-виведення)
Більшість критеріїв прийнятності можна задокументувати в одному з цих двох форматів. Однак команда може використовувати інший, спеціальний формат, якщо критерії прийнятності чітко визначені та однозначні.
Розробка керована приймальним тестуванням – Acceptance Test-driven Development (ATDD)
ATDD — це підхід, який передбачає спочатку тестування. Тестові кейси створюються до впровадження історії користувача. Тестові кейси створюють члени команди з різними точками зору, наприклад, клієнти, розробники та тестувальники (Adzic 2009). Тестові кейси можуть виконуватися вручну або автоматизовано.
Першим кроком є специфікаційний семінар, де члени команди аналізують, обговорюють і пишуть історію користувача та (якщо ще не визначено) її критерії прийнятності. Під час цього процесу вирішуються проблеми неповноти, двозначності або розв’язуються дефекти в історії користувача. Наступним кроком є створення тестових кейсів. Це може робити як команда в цілому, так і тестувальник окремо. Тестові кейси базуються на критеріях прийнятності та можуть розглядатися як приклади того, як працює програмне забезпечення. Це допоможе команді правильно реалізувати історію користувача.
Оскільки приклади та тести однакові, ці терміни часто використовуються як синоніми. Під час планування тесту можна застосовувати інші методи тестування.
Як правило, перші тестові кейси є позитивними, підтверджують правильну поведінку без винятків або умов помилки та включають послідовність дій, які виконуються, якщо все йде, як очікувалося. Після того, як позитивні тести зроблені, команда повинна провести негативне тестування. Нарешті, команда також повинна охоплювати нефункціональні характеристики якості (наприклад, ефективність продуктивності, зручність використання). Тестові кейси мають бути виражені у спосіб, зрозумілий для зацікавлених сторін. Як правило, тестові кейси містять речення природною мовою, що включають необхідні попередні умови (якщо такі є), вхідні дані та постумови.
Тестові кейси повинні охоплювати всі характеристики історії користувача і не повинні виходити за межі історії. Однак критерії прийнятності можуть деталізувати деякі проблеми, описані в історії користувача. Крім того, два тести не повинні описувати однакові характеристики історії користувача.
Коли вони записуються у форматі, який підтримується інфраструктурою автоматизації тестування, розробники можуть автоматизувати тестові випадки, написавши допоміжний код під час реалізації функції, описаної в історії користувача. Після цього приймальні випробування стають вимогами до виконання.
В цьому відео починаємо працювати з секцією 4.5.
00:00:41 Collaboration-based Test Approaches
00:01:45 Collaborative User Story Writing
00:07:11 Acceptance Criteria
00:10:59 Acceptance Test-driven Development (ATDD)