База знань

Test Case

Test Case – це тестовий артефакт, суть якого полягає у виконанні певної кількості дій і / або умов, необхідних для перевірки певної функціональності програмної системи, що розробляється .

Test Case – це професійна документація тестувальника, суть якої полягає у виконанні певної кількості тестів і / або умов, необхідних для перевірки певної функціональності розроблюваного програмного забезпечення.

Test Case – це послідовність дій, по якій можна перевірити, чи відповідає система або тестована функція заявленим вимогам.

Структура даного артефакту полягає в «трійці»:

– що треба зробити (Action);

– очікуваний результат (Expected result);

– фактичний результат (Test result).

Безпосередньо сам  Test Case складається з 3 частин:

  • Передумови (Pre-Conditions) – або список кроків, які приводять систему ,що перевіряється до стану, придатного для тестування, або список перевірок умов того, що система вже знаходитися в необхідному стані.
  • Опис тестового випадку (Test Case Description) – список дій, за допомогою яких здійснюється основна перевірка функціоналу (після якої і звіряється фактичний результат з очікуваним).
  • Post Conditions (Післяумови) -список дій, які повертають систему в початковий стан. Post Conditions не є обов’язковою частиною. Це, швидше за все, правило хорошого тону: “насмітив – прибери за собою”. Це особливо актуально при автоматизованому тестуванні, коли за один прогін можна наповнити базу даних сотнею або навіть тисячею некоректних документів.
  • testcase

Складові Test Cases в цілому:

– номер (ID);

– мета;

– попередні кроки;

– кроки;

– очікуваний результат;

– результат тесту.

Кожен виконаний Test Case, дає нам один з трьох результатів:

– позитивний результат, якщо фактичний результат дорівнює очікуваного результату;

– негативний результат, якщо фактичний результат не дорівнює очікуваному результату. У цьому випадку, знайдена помилка;

– виконання тесту блоковано, якщо після одного з кроків продовження тесту неможливо. У цьому випадку так само, знайдена помилка.

Чого не повинно бути в Test Case:

– залежностей від інших тест-кейсів;

– нечіткого формулювання кроків або очікуваного результату;

– відсутності необхідної для проходження тест-кейса інформації;

– зайвої деталізації.

Види Test Cases:

позитивний Test Case. Даний вид використовує лише коректні дані і перевіряє те,  чи  програмне забезпечення, що розробляється правильно виконує викликану функцію;

негативний Test Case. Даний вид використовує як коректні, так і не коректні дані (мінімум один не коректний параметр) і ставить за мету перевірку виняткових ситуацій.

Переваги  Test Cases:

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

Недоліки Test Cases (випливають один з іншого):

  1. Дуже багато копіпаст, багато копіпаст, копіпаст. Test Cases “ввести в поле тільки символи, тільки числа, рядок нульової довжини і т. д.” будуть дуже схожі один на одного, перші кроки однакові і, поклавши руку на серце, будуть копіпаст. Спробуйте написати хоча б три Test Cases на один функціонал і відразу побачите цю проблему.
  2. Складно підтримувати. Уявіть, що вкладку “Мешканці” перейменували в “Замовники”. Щоб актуалізувати Test Cases, треба внести зміни в сотні сценаріїв, що утомливо навіть в режимі “Ctrl + C, Ctrl + V”.
  3. Неактуальний стан. Test Cases часто створюють в режимі “копіпаст” один від одного, і часто в них залишаються неактуальні частини з вихідного кейса, які забули змінити.

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

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

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

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

– налагоджувати ефективну комунікацію з розробниками, менеджерами і користувачами для збору даних по проекту і проведення QA-аналізу;

– правильно розставляти пріоритети, відокремлювати важливіше від менш значущого;

– однаково легко бачити систему в цілому і проводити декомпозицію, щоб була перевірена кожна окрема фіча;

– точно формулювати думки і вміти їх донести до колег і замовника;

– вміло застосовувати техніки тест-дизайну.

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

Набагато більше інформації на курсі базовий модуль тестування