Всі тест-документи-аналіз та аналіз вимог

План уроку:

Процес тестування. SDLS та STLS
Документи планування тестування
-Стратегія тестування
-Тест-план
-Практичний Тест-план
Документи проведення тестування
-Чек-лист
-Тест-кейс
-Тест-сценарій
-Тестова матриця
Документи звітності про тестування
-Матриця відповідності вимог
-Звіт тестування
-Звіт про дефект

Документи планування тестування

Тест-план (Test Plan) – це документ, що описує весь об`єм робіт з тестування, починаючи з опису об'єктів, що тестуються, стратегії, розкладу, критеріїв початку та закінчення тестування, до необхідного в процесі роботи обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення.

Більш детально тест план буде розглянуто у наступних лекціях.

Структура тест-плану:

1. Що треба тестувати (об'єкт тестування: система, застосунок, обладнання);

2. Що будете тестувати (перелік функцій і компонент тестованої системи);

3. Як будете тестувати (стратегія тестування – види тестування і їх застосування);

4. Тестові оточення, на яких необхідно перевіряти програмний продукт;

5. Коли будете тестувати (послідовність проведення робіт: підготовка, тестування, аналіз результатів, облік залежностей тестових активностей від завдань розробки та суміжних груп);

6. Ризики та стратегії щодо їх вирішення;

7. Перелік узгоджуючих осіб;

8. Прийняті стандарти і шаблони;

9. Критерії початку і закінчення тестування.

Стратегія тестування

Стратегія тестування – це неідеалізований документ про підходи тестування, що прийняті в рамках

організації або окремого департаменту.

Стратегія визначає типи тестів, які потрібно виконувати для даного функціоналу системи, включає

опис необхідних підходів з точки зору цілей тестування, і може задавати описи або вимоги до

необхідних для проведення тестування інструментів та інфраструктури.

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

Стратегія відповідає на питання:

•Як, яким чином тестування гарантує що даний функціонал працює? Через що може бути призупинено тестування?

•Що треба зробити та які інструменти необхідні для досягнення цілей тестування?

•Коли певний функціонал буде тестуватися і, відповідно, коли чекати на результати?

Практичний Тест-план

Практичний Тест-план – підхід планування тестування можна застосувати не тільки для проєкта, а і для окремих фіч.

Таким чином ми можемо гарантувати якісне і контрольоване тестування кожної окремої частини проєкту.

Писати такий план краще всього у Jira або Confluence з посиланням на задачу

Фіча – можливість покупки квитка тільки в один бік.

Як ви підготуєтеся до проведення тестування?

Що вам треба знати і що зробити?

написати тест-кейси на новий функціонал
дізнатися, що вже покрито:

- які тести вже є;

-які тести автоматизовані;

-які є юніт-тести;

-які області застосунку можуть бути зачеплені.

Рекомендовані блоки для тест-плану певної задачі:

Основні:

• Що тестувати – певна фіча, її аспекти;

• Як тестувати – які види тестування застосовуються:

(ручне/авто/перфоманс), на яких рівнях (unit / UI / etc);

• Де тестувати – яке середовище використовується;

• Чим тестувати – нові і вже існуючі тест-кейси + регресія.

Інформаційні:

• Хто тестує – корисно, якщо бере участь більше одного тестувальника;

• Версії компонентів – корисно вказати для відстеження стабільності тестування;

• Посилання на завдання, яке тестується, у Project Management System.

Додаткові:

• How-to – вкажіть детальні інструкції з усіх неочевидних/нестандартних

дій, необхідних для тестування.

Документи проведення тестування

Різні тест-формати

•Чек-ліст (Check List) — список запланованих тестів, без подробиць, кроків, очікуваних результатів. Може існувати також у більш деталізованій версії – з пріоритетами, тестовими даними і т.д.

•Тестовий випадок (Test Case) — докладні інструкції щодо виконання перевірки, з перед- та пост-умовами,

кроками та очікуваними результатами.

•Тестовий набір (Test Suite) – набір тест-кейсів за певною ознакою, найчастіше функціоналом.

•Тестовий сценарій (Test Scenario) — тести, орієнтовані на відтворення поведінки користувача, взаємодії між

компонентами.

•Матриця тестування (Test Matrix) – тести, які необхідно областей/компонентів/конфігурацій, але з однаковими кроками тестування.

Check List

Check List це список перевірок програми або окремої її області.

Коли використовувати:

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

Detailed Check List це форма чеклісту з більшою кількістю даних та більш складною стуктурою.

Коли використовувати:

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

Які можуть бути дані:

Priority
Area
Test Run
Link to Requirement
Platform (OS or Browser)
Etc.

Test Case

Тест-кейс – це повністю структурований чек-лист з акцентом на тому, як виконати перевірку.

Коли використовувати:

якщо не підійшли більш легкі формати;

при високій складності перевірок.

коли є комплексні умови виконання перевірок

Test Case. Поля

Test Scenario

Тест-сценарій акцентує на послідовності кроків як на єдиному цілому.

Коли використовувати:

для проведення тестування на рівні користувача.

Test Matrix

Коли використовувати

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

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

Як обрати формат

Запитання для уточнення:

•Чи потрібна замовнику особлива форма тестової документації, якій ми повинні відповідати?

•Чи ми повинні використовувати тест-кейс, або ж альтернативна форма тестової документації буде більш ефективною?

•Поміркуйте про досвідченість команди та її розширення / зміну — який рівень деталізації буде достатнім для новачків/джуніорів ?

Документи звітності про тестування

Traceability Matrix

Матриця відповідності вимог це таблиця, яка містить відповідності функціональних вимог продукту і

підготовлених тестових випадків.

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

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