Техніки тест-дизайну для «чайників»

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Привіт всім теперішнім і майбутнім тестувальникам. Мене звати Галина Захарова і я працюю QA Engineer у ІТ-компанії Customertimes. Ви вже могли читати мої статті на DOU про те, як я шукала роботу в ІТ та як пройшов мій перший рік в ІТ.

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

Пам’ятаю, як передивлялась певні відео декілька разів, щоб зрозуміти деякі з технік. Тому я розписала основні з них (часто використовувані), наводячи приклади. Сподіваюсь, в мене вийде зробити цю тему зрозумілішою. Наскільки мені це вдалось, ви можете написати у коментарях.

Мій YouTube: www.youtube.com/@qaquest_HalynaZakharova

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

Equivalence Partitioning (Еквівалентний розподіл)

Техніка «Equivalence Partitioning» — це спосіб створення тестових випадків, який дозволяє ефективно та економно перевірити програму/ систему. Замість того, щоб випадково обирати тести, ми розділяємо можливі дані вхідних значень на групи, які поводяться однаково. Вони [групи] можуть бути позитивними та негативними.

Ось приклад: уявіть, що ви тестуєте програму для обчислення віку людини за її датою народження. Ви знаєте, що програма приймає дату народження як вхідні дані і вираховує вік. Замість того, щоб створювати тестові випадки для кожної окремої дати народження, ви застосовуєте техніку «Equivalence Partitioning».

По-перше, треба розділити можливі дати народження на групи (візьмемо позитивні):

1. Дитячі дати народження (наприклад, менше ніж 12 років).
2. Підліткові дати народження (наприклад, від 12 до 18 років включно).
3. Дати народження для дорослих (наприклад, від 19 до 60 років включно).
4. Дати народження для літніх людей (наприклад, старше 60 років).

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

Не забуваємо про негативні сценарії — це ситуації, коли програма повинна обробити або повідомити про помилку через некоректні або недійсні дані вхідних значень. Ось декілька прикладів:

1. Введення некоректної дати: вводимо дату народження у неправильному форматі або з не дійсними значеннями. Наприклад, введення дати у форматі «місяць/день/рік» з недійсним числом дня або місяця (13 місяць, 30 лютого і т.д.).
2. Дати у майбутньому.
3. Дати з неправильним порядком: наприклад, ми вводимо місяць, потім рік, а потім день, замість очікуваного порядку рік-місяць-день.
4. Обробка некоректних символів: перевірка, як програма реагує на некоректні символи або літери, які не пов’язані з датою народження.

Використання «Equivalence Partitioning» допомагає зменшити кількість тестів, які потрібно виконати, при цьому ефективно перевіряючи різні сценарії використання програми.

Boundary Value Analysis (Аналіз граничних значень)

Техніка Boundary Value Analysis (аналіз граничних значень) допомагає знайти помилки на межах діапазонів (відрізків) даних. Вона спрямована на перевірку поведінки програми на мінімальних та максимальних значеннях вхідних даних, а також на значеннях, які знаходяться поза межами діапазонів.

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

1. Мінімальне значення (Lower Boundary): візьмемо якесь найменше значення для дати народження — нехай це буде 1 січня 1930 року. Вводимо цю дату і перевіряємо, чи правильно програма обчислює вік. Програма повинна правильно обчислити.
2. Максимальне значення (Upper Boundary): тепер візьмемо якесь найбільше значення для дати народження. Наприклад, 31 грудня 2050 року (уявімо, що сьогодні 31 грудня 2050 року, поживемо трохи у майбутньому). Вводимо цю дату і впевнюємось, що програма правильно обчислила вік.
3. Значення неподалік границь (Near the Boundaries): а тепер перевіримо, як програма поводиться з датами, які знаходяться один день до мінімальної дати та один день після максимальної дати. Тобто 31 грудня 1929 року (один день перед мінімальним значенням) і 1 січня 2051 року (один день після максимального значення: знову уявляємо, що завтра 1 січня 2051 року). Вводимо ці значення і впевнюємось, що програма їх відхиляє, тому що все, що поза визначеними границями — невалідне.

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

Decision Table Testing (Тестування таблиці рішень)

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

Для прикладу візьмемо ту саму програму з обчислення віку. Для Decision Table Testing потрібно визначити всі можливі умови та дії, які програма може виконувати:

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

Використання Decision Table Testing допомагає перевірити всі можливі комбінації умов та дій, забезпечуючи повне тестування програми на різних сценаріях та забезпечуючи, що програма поводиться коректно для різних вхідних даних або некоректно, якщо будемо використовувати не валідні значення, такі як спецсимволи (наприклад: !(%№«;), літери, неправильний формат дати.

State Transition Testing (Тестування зміни станів)

State Transition Testing (тестування зміни станів) — техніка тест-дизайну, що допомагає перевірити поведінку програми в різних станах та переходах між ними. Для тестування дати народження за допомогою State Transition Testing, ми визначимо стани програми та умови, які викликають перехід між цими станами.

Стани:

1. Стан «Початковий» — коли програма тільки запускається або ще не отримала вхідних даних (дата народження).
2. Стан «Вік обчислений» — коли програма успішно обчислила вік після вводу дати народження.
3. Стан «Помилкова дата» — коли користувач ввів недійсну дату народження (наприклад, 30 лютого).
4. Стан «Неповнолітній» — коли вік обчислено і виявлено, що особа неповнолітня.
5. Стан «Дорослий» — коли вік обчислено і особа вважається дорослою.
6. Стан «Літній» — коли вік обчислено і особа вважається літньою.

Переходи:

1. Зі стану «Початковий» програма переходить до стану «Вік обчислений», якщо ви вводите правильну дату народження.
2. Зі стану «Початковий» програма переходить до стану «Помилкова дата», якщо вводите недійсну дату (наприклад, 30 лютого).
3. Зі стану «Вік обчислений» програма переходить до стану «Неповнолітній», «Дорослий» або «Літній», залежно від обчисленого віку.

Тепер, для тестування State Transition Testing, нам потрібно перевірити кожен стан і перехід між ними:

1. Перевіримо стан «Початковий», впевнившись, що програма коректно переходить до наступного стану при правильному введенні дати народження.
2. Перевіримо стан «Початковий», переконавшись, що програма виводить правильне повідомлення про помилку, якщо ввели недійсну дату народження.
3. Перевіримо стан «Вік обчислений», переконавшись, що програма правильно визначає вік на підставі правильної (існуючої) дати народження.
4. Перевіримо стан «Вік обчислений», переконавшись, що програма визначає неповнолітніх, дорослих і літніх з правильними діапазонами віку.
5. Перевіримо стан «Помилкова дата», переконавшись, що програма правильно виводить повідомлення про недійсну дату.

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

Use Case Testing (Тестування за допомогою сценаріїв використання)

Use Case Testing спрямовано на тестування різних сценаріїв використання програми на основі взаємодії з користувачем або зовнішніми системами. Для тестування дати народження нам потрібно визначити різні сценарії, які можуть виникати при взаємодії з програмою. Візьмемо до прикладу наступні сценарії:

1. Введення правильної дати народження: ми вводимо правильну дату народження, програма успішно обчислює вік та відображає результат.
2. Введення недійсної дати народження: ми вводимо недійсну дату (наприклад, 30 лютого або 31 квітня), програма виводить повідомлення про помилку та не обчислює вік.
3. Введення неправильного формату дати: ми вводимо дату у неправильному форматі (наприклад, лише рік або місяць), програма повинна показати повідомлення про помилку.
4. Введення дати народження, яке буде у майбутньому: ми вводимо дату народження, яка буде в майбутньому, програма повинна показати повідомлення про помилку.
5. Введення дати народження неповнолітнього: ми вводимо дату народження неповнолітнього (наприклад, 1 січня 2007 року), програма повинна показати відповідне повідомлення про те, що особа неповнолітня.
6. Введення дати народження літньої людини: ми вводимо дату народження, яка відповідає віку літньої людини (наприклад, 1 січня 1950 року), програма повинна показати відповідне повідомлення про те, що особа літня.
7. Введення дати народження дорослої людини: ми вводимо дату народження, яка відповідає віку дорослої людини (наприклад, 1 січня 1990 року), програма повинна показати відповідне повідомлення про те, що людина доросла.

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

Наступні дві техніки тест-дизайну базуються на досвіді у тестуванні.

Error Guessing (Вгадування помилок)

Error Guessing (вгадування помилок) — це неформальний підхід (техніка тест-дизайну), коли тестувальник використовує свої знання та досвід для припущення можливих помилок у програмі.

На прикладі дати народження уявімо, які помилки можуть бути допущені:

1. Програма може неправильно обробити дати у неправильному форматі, наприклад, замість «день/місяць/рік» будуть введені дані у «місяць/день/рік» або взагалі без роздільників («/» - оцей значок).
2. Програма може не перевіряти введені дані на коректність. Наприклад, ми введемо неіснуючі дати (30 лютого, 31 квітня, 13 місяць, рік у майбутньому), спецсимволи, літери тощо і програма пропустить далі.
3. Програма неправильно обчислює вік.
4. Програма може не надати повідомлення про помилки, коли ми вводимо некоректні дані.

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

Exploratory Testing (Дослідницьке тестування)

Exploratory Testing (дослідницьке тестування) — техніка тест-дизайну, яка полягає у виявленні помилок та некоректних поведінок програми «на льоту». В дослідницькому тестуванні немає заздалегідь написаних тест-кейсів, і ми маємо активно вивчати програму, шукаючи помилки та випадкові сценарії, які можуть призвести до некоректної роботи, спираючись на свій досвід та знання.

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

1. Перевіряємо, чи правильно програма обчислює вік, якщо правильно ввести дату народження.
2. Перевірка реакції на недійсні дати.
3. Граничні значення. Про цю техніку писала вище, тому ви вже знаєте, які саме дані треба вводити.
4. Неправильні формати. Наприклад, коректний формат «день-місяць-рік», а ми пробуємо ввести:
   * місяць-день-рік;
   * рік-день-місяць;
   * день-рік-місяць.
5. Тестування взаємодії з іншими частинами системи: наприклад, як використовується обчислений вік в інших частинах програми.

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

Checklist-based Testing (тестування на основі чек-листів)

Checklist-based Testing (тестування на основі чек-листів) — це техніка тест-дизайну, при якій тестувальники використовують попередньо підготовлені чек-лісти або переліки критичних точок для перевірки, щоб переконатися, що вони не пропустили нічого важливого та покрили критичні сценарії.

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

Приклад Checklist-based Testing для дати народження може включати такі перевірки:

1. Правильність обчислення віку.
2. Поведінка програми при неправильному форматі дати.
3. Поведінка програми при введенні недійсних дат, наприклад, 30 лютого.
4. Відображення помилки при некоректних даних.
5. Поведінка програми при введенні дат, що належать до майбутнього.
6. Поведінка програми при введенні дат, що вказують на неповнолітніх або літніх користувачів.
7. Перевірка обробки спеціальних дат: переконатися, що програма правильно обробляє спеціальні дати, такі як 29 лютого високосного року або дата, коли користувач народився в перехідний день.
8. Перевірка обробки масового вводу дат: Спробуйте ввести багато дат народження одночасно, використовуючи різні браузери.
9. Перевірка локалізації.
10. Поведінка програми, коли дату не було введено (залишаємо поля пустими).
11. Перевірка, що програма вимагає введення дати народження в правильному форматі (наприклад, день/місяць/рік або рік-місяць-день).
12. Перевірка взаємодії з іншими полями форми, якщо є інші поля у формі.

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

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

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

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

Мій YouTube: www.youtube.com/@qaquest_HalynaZakharova