State Transition

Продовжуємо розбирати техніки тест дизайну.

Ця техніка зазвичай застосовується в тих випадках, коли в ПЗ є об’єкти зі станами, наприклад: товар в інтернет магазині (є в наявності, в корзині, куплений, доставлений) чи персонаж в грі (виконує квест, в бою, відпочиває, offline). Давайте візьмемо приклад з титульної картинки статті – вільну варіацію станів багу в Jira та розробимо для нього тести.

І, перш за все, – позитивні тести. Методичка iSTQB каже нам, що в залежності від цілей, кількість тестів, що ми можемо створити за допомоги цієї техніки, може бути різна. Якщо ми покриваємо всі стани багу – нам потрібен лише 1 тест:

1. Open -> In Progress -> Done -> Closed

Якщо ми хочемо покрити всі переходи між станами, то тестів треба більше:

1. Open -> In Progress -> Done -> Closed (happy flow)
2. Open -> In Progress -> Open (stop progress)
3. Open -> In Progress -> In Progress (update)
4. Open -> In Progress -> Done -> Open (reopen)
5. Open -> Closed (reject)

У допитливих і уважних вже мало б виникнути кілька питань на кшталт “чому не перевірити кожну стрілочку окремо?”, “чому всі тести починається з Open?”. Тут все залежить від конкретної системи і задач тесту – якщо ми маємо можливість перед кожним тестом створити об’єкт в потрібному статусі як precondition і зробити тест “на одну стрілочку” – краще так і робити, оскільки чим менше кроків в тесті – тим менша вірогідність, що тест не пройде на перших, підготовчих кроках. Якщо ми говоримо про E2E – то краще робити всі тести “від початку і до кінця”, оскільки часто можна зустріти ситуацію, що синтетичні тести Done -> Closed проходять, а повний happy flow тест – ні, через певні додаткові параметри об’єкту, обов’язкові на одних кроках і опціональні на інших.

Але на цьому техніка не вичерпана, оскільки ми розглянули лише позитивні тести. Які негативні тести ми можемо виконати? Теоретично – всі стрілочки, яких нема на схемі – негативні тести, а практично? Кілька років тому моя коллега допомогла мені розібратись, і зараз ми розпишемо негативні тести для нашого прикладу. Спочатку, розпишемо всі стани та переходи у вигляді таблиці, вказуючи кількість переходів цифрами. В нашому випадку немає більш ніж одного переходу між двома станами, тому всюди будуть “1”:

А тепер впишемо в цю таблицю всі негативні тести:

В результаті в нас є 9 негативних тестів на переходи між станами. Просто! Але як це протестувати? Тут все знову залежить від ПЗ, що ми тестуємо. Можна змінювати стан об’єкту в БД перед тестом, наприклад, або, як мінімум, впевнитись, що в інтерфейсі користувача відсутні засоби для переведення об’єкту поза прописаними переходами. В моєму випадку я відкривав сторінку об’єкта в двох браузерах – в одному змінював стан об’єкту, в іншому – теж намагався змінити стан, спостерігаючи поведінку ПЗ. Наприклад тест Closed -> Open.

Summary: Closed -> Open
Preconditions:
 - Ticket in status Done
 - Ticket opened in 2 browsers
Steps:
1. In browser 1 close ticket
2. In browser 2 reopen ticket
Expected result:
 - Error displayed: "Ticket state was changed. Please refresh page"

Власне, ніякої магії. Напишіть в комментах, а як ви тестує state transition?