Комбінування технік тест-дизайну для побудови тестового покриття

Є декілька найбільш відомих технік тест-дизайну: Equivalence Classes (еквівалентні класи), Boundary Values (граничні значення), Pairwise (попарне тестування), Decision Table (таблиця прийняття рішень), State-Transition Diagram (діаграма переходу станів). Можна їх використовувати й окремо, але краще їх все ж комбінувати, наприклад, Equivalence Classes, Boundary Values, Pairwise добре працюють разом. Про це і поговоримо

Візьмемо за приклад який-небудь явний застосунок з функціоналом створення подій у власному календарі. В цьому модулі є проста форма з полями для заповнення та кнопка “Create”, щоб створити подію.

 

Поля наступні: Name, Date, Time FROM, Time TO, Participant, Description, File

Для цих полів сформовані такі вимоги:

1. input field “Name”:
   - required (поле обов'язкове до заповнення)
   - unique (в базі не може існувати 2-х подій с однаковими назвами)
   - MAX characters accepted = 30, all characters allowed
2. field “Date”:
   - required (поле обов'язкове до заповнення)
   - allows entering date manually in the format dd/mm/yyyy OR by selecting a required date from a date picker
   - only today’s date or future date is allowed
3. fields “Time FROM” and “Time TO”:
   - required (поля обов'язкові до заповнення)
   - allows entering time manually in the format 00:00 (without seconds)
   - MIN interval allowed between times = 5 min
4. input field “Participant”:
   - required (поле обов'язкове до заповнення)
   - only 1 participant can be entered
   - type = email (згідно з нашою уявною логікою, нашого уявного застосунку, учаснику буде надісланий лист із запрошенням приєднатися до події)
5. text area “Description”:
   - NOT required (поле опціональне до заповнення)
   - MAX characters accepted = 100, all characters allowed
6. field “File”:
   - NOT required (поле опціональне до заповнення)
   - only 1 file can be attached
   - allows opening the system folder from which we can select a file for attachment
   - MAX file size allowed = 5 MB
   - files of all formats and extensions are supported

Отже, ознайомившись із вимогами до полів і елементами форми, ми можемо сформувати еквіваленті класи для кожного поля. Почнемо з позитивних еквівалентних класів (як варіант):

Name:

1. any valid unique value within 30 characters

Date:

1. current date
2. future date

Time FROM/TO:

1. any interval within a day
2. AM/PM transition
3. 00:00-00:05
4. 23:54-23:59

Participant:

1. any valid email

Description:

1. any valid value within 100 characters
2. empty

File:

1. any file of size 5 MB or less
2. no file attached

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

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

 

Тепер сформуємо негативні еквіваленти класи (тут як раз у пригоді стане техніка граничних значень):

Name:

1. more than 30 characters entered
2. NOT unique
3. empty

Date:

1. past date
2. not existing date (like 32/13/2002)
3. empty

Time FROM/TO:

1. time FROM is later than time TO
2. not fully entered time (like 11:_ _)
3. empty (both or one field only)

Participant:

1. incorrectly formatted email
2. empty

Description:

1. more than 100 characters entered

File:

1. file of more than 5 MB size attached

Тепер коли в нас є сформований список класів, ми можемо сформувати набори тестових даних, які ми будемо використовувати для тестів. Для цього як раз використаємо техніку Pairwise (щоб знайти унікальні пари значень і зменшити кількість непотрібних перевірок). Зручний інструмент для цього — PICT. Маємо наступне:

 POSITIVE CASES

	Name	Date	Time FROM/TO	Participant	Description	File
1	any valid unique value within 30 characters	current date	AM/PM transition	any valid email	any valid value within 100 characters	any file of size 5 MB or less
2	any valid unique value within 30 characters	future date	23:54-23:59	any valid email	empty	any file of size 5 MB or less
3	any valid unique value within 30 characters	future date	any interval within a day	any valid email	any valid value within 100 characters	no file attached
4	any valid unique value within 30 characters	current date	AM/PM transition	any valid email	empty	no file attached
5	any valid unique value within 30 characters	future date	AM/PM transition	any valid email	any valid value within 100 characters	no file attached
6	any valid unique value within 30 characters	current date	00:00-00:05	any valid email	empty	any file of size 5 MB or less
7	any valid unique value within 30 characters	current date	any interval within a day	any valid email	empty	any file of size 5 MB or less
8	any valid unique value within 30 characters	future date	00:00-00:05	any valid email	any valid value within 100 characters	no file attached
9	any valid unique value within 30 characters	current date	23:54-23:59	any valid email	any valid value within 100 characters	no file attached

 

 NEGATIVE CASES

	Name	Date	Time FROM/TO	Participant	Description	File
1	NOT unique	past date	time FROM is later than time TO	empty	more than 100 characters entered	file of more than 5 MB size attached
2	more than 30 characters entered	empty	empty (both or one field only)	incorrectly formatted email	more than 100 characters entered	file of more than 5 MB size attached
3	NOT unique	empty	not fully entered time (like 11:_ _)	incorrectly formatted email	more than 100 characters entered	file of more than 5 MB size attached
4	empty	not existing date (like 32/13/2002)	not fully entered time (like 11:_ _)	empty	more than 100 characters entered	file of more than 5 MB size attached
5	more than 30 characters entered	not existing date (like 32/13/2002)	time FROM is later than time TO	incorrectly formatted email	more than 100 characters entered	file of more than 5 MB size attached
6	more than 30 characters entered	past date	not fully entered time (like 11:_ _)	empty	more than 100 characters entered	file of more than 5 MB size attached
7	NOT unique	not existing date (like 32/13/2002)	empty (both or one field only)	empty	more than 100 characters entered	file of more than 5 MB size attached
8	empty	past date	empty (both or one field only)	incorrectly formatted email	more than 100 characters entered	file of more than 5 MB size attached
9	empty	empty	time FROM is later than time TO	empty	more than 100 characters entered	file of more than 5 MB size attached

 

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

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

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

• Як тільки ми провели 1 тест (1 рядок) негативних, ми змінюємо негативне значення на позитивне в 1 полі (будь-якому) і натискаємо “Create” (подія все одно не повинна зберігатися);
• Потім знову змінюємо негативне значення на позитивне в іншому полі і знову натискаємо “Create”;
• І так до тих пір поки ми не знайдемо багу чи не дійдемо до валідних значень в усіх полях і до успішного створення події

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

Наведений у цій статті приклад лише один з можливих способів скомбінувати техніки тест-дизайну. Експериментуйте, фантазуйте, продумайте свій підхід в залежності від вашого проєкту та можливостей.😉

Саме так наша офшорна QA-команда планує покриття тестами для продуктів клієнтів.