Візуалізація тестування та покриття

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

Візуалізація тестового покриття дозволяє оцінювати якість тестування: наскільки добре і ретельно був або буде перевірений продукт, яким областям не вистачає уваги, де основні ризики і який загальний прогрес.

Навіщо оцінювати тестове покриття?

Будь-які метрики оцінки – трата часу. У цей час можна тестувати, заводити баги, готувати автотести. Яку ж користь ми можемо отримати завдяки метрикам тестового покриття, пожертвувавши часом на тестування?

1. Пошук своїх слабких зон. Це потрібно для того, щоб дізнатися, де потрібні поліпшення, виявити функціональні області не покриті тестами, знайти неперевірені блоки і виявити області з найбільшим ризиком пропуску помилок.
2. Рідко за результатами оцінки покриття ми отримуємо 100%. Що покращувати? Куди йти? Який зараз відсоток? Як ми його підвищимо будь-яким завданням? Як швидко ми дійдемо до 100? Всі ці питання вносять прозорість і зрозумілість нашого процесу, а відповіді на них дає оцінка покриття.
   
3. Фокус уваги. Припустимо, в нашому продукті 50 різних функціональних зон. Виходить нова версія і ми починаємо тестувати першу з них, знаходимо там помилки, зміщені на пару пікселів кнопки та інші дрібниці... І ось час на тестування завершено і ця функціональність перевірена детально... А решта 49? Оцінка покриття дозволяє нам пріоритезувати завдання виходячи з поточних реалій і термінів.

Матриця відповідності вимог

Для валідації і візуалізації покриття продукту тестами QA-інженери використовують Матрицю відповідності вимог («Traceability Matrix») – двовимірну таблицю, яка містить відповідності функціональних вимог (functional requirements) продукту і підготовлених тестових сценаріїв (test cases). У заголовках рядків таблиці розташовані вимоги, а в заголовках колонок – тестові сценарії або навпаки. На перетині – відмітка, яка означає, що вимога поточної колонки покрита тестовим сценарієм поточного рядка. Матриця зазвичай зберігається у вигляді електронної таблиці.

Таблиця дає візуальне відображення двох параметрів:

• наявність в системі вимог, які ще не покриті (якщо у вимоги немає жодного перетину з тест-кейсами (достатня умова));
• чи є в системі надмірне тестування – якщо вимоги мають кілька перетинів (необхідна умова).

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

Тому матриця має вигляд таблиці, кожен рядок якої містить:

• номер та опис завдання на розробку з таск-трекера (№, issue for development);
• логічний блок, до якого належить завдання (опціонально) (block of feature);
• атомарна вимога або приймальний критерій (acceptance criteria);
• пріоритет (priority);
• номер та опис відповідного тестового артефакту (test-case).

Таке трасування дозволяє:

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

Приклади візуалізації тестування і покриття

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

• матриця трасування вимог до мобільного пристрою зі співвідношенням статусів

• матриця трасування веб-додатків з поділом за розділами

• матриця трасування веб-продукту за модулями з ітераціями

• матриця трасування інтернет-магазину з доставки їжі

Висновки

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

В цій статті було розглянуто такий тестовий артефакт, як «Матриця відповідності вимог». Одна з основних її переваг – наочність. Якщо вона підтримується в актуальному стані, то можна відразу побачити «білі плями» і зосередитися на них.

Крім того, матриця трасування дозволяє зв'язати знайдені баги до вимог, що дозволяє тестувальникам більш ефективно «захищати» дефекти. Якщо ви можете вказати, яка саме вимога порушена в конкретному випадку, розробник вже не зможе заявити, що «це не баг, це фіча» :)