Manual QA

Тестова документація

план, кейси, чеклісти, звіти

Що таке тест-план і що в ньому?

Документ, що описує що, як, коли і ким тестуємо. Типові розділи:

Обсяг: що тестуємо і що не тестуємо.
Підхід: рівні й види тестування, ручне чи автоматизоване.
Середовища, тестові дані, інструменти.
Критерії входу і виходу (коли починаємо, коли готово до релізу).
Ризики й план дій щодо них.
Ролі, графік, артефакти.

В Agile тест-план часто коротший і живий — сторінка в Confluence на реліз чи фічу.

На співбесіді: Тест-план описує, що ми тестуємо і що ні, яким підходом, на яких середовищах і з якими даними, критерії входу й виходу, ризики та ролі. В Agile я тримаю його коротким і живим, наприклад сторінкою в Confluence на реліз.

Чим тест-стратегія відрізняється від тест-плану?

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

План — конкретне застосування стратегії до проєкту, релізу чи фічі: обсяг, графік, люди, ризики.

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

З чого складається хороший тест-кейс?

ID і зрозуміла назва: що перевіряємо.
Передумови: стан системи, користувач, дані.
Кроки — короткі, по одній дії.
Очікуваний результат — конкретний і перевірюваний.
Пріоритет, зв'язок з вимогою, тип (позитивний чи негативний).

Критерій якості: інший тестувальник пройде кейс без питань і однаково оцінить результат. Один кейс — одна перевірка.

ID:        TC-PAY-014
Назва:     Переказ, що рівно вичерпує денний ліміт
Передумови: Користувач залогінений, денний ліміт 10 000 грн,
            сьогодні вже переказано 9 000 грн, баланс 5 000 грн
Кроки:
  1. Відкрити «Переказ на картку»
  2. Ввести валідний номер картки отримувача
  3. Ввести суму 1 000.00
  4. Підтвердити переказ
Очікувано: Переказ успішний; залишок ліміту 0.00;
           баланс 4 000.00 мінус комісія за тарифом
Пріоритет: High   Вимога: REQ-LIM-03

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

Коли тест-кейси, а коли чеклісти?

Чекліст — список перевірок без детальних кроків. Швидко писати й підтримувати, підходить для досвідченої команди, smoke, exploratory, стабільних простих частин.

Тест-кейс — детальний сценарій. Потрібен для складної логіки, нових людей у команді, регуляторних вимог і сценаріїв, які потім автоматизують.

На співбесіді: Чеклісти швидші, і я використовую їх для smoke, дослідницьких сесій і стабільних простих частин. Детальні тест-кейси пишу для складної бізнес-логіки, для сценаріїв, які піде автоматизувати, і там, де потрібна аудиторська простежуваність, як у фінтеху.

Що таке матриця простежуваності (traceability matrix)?

Таблиця зв'язків «вимога → тест-кейси → результати → дефекти». Показує, чи кожна вимога покрита тестами, що зламалося і які вимоги зачепить зміна.

У Jira це часто робиться зв'язками між story, тест-кейсами (Zephyr, Xray) і багами.

На співбесіді: Матриця простежуваності зв'язує вимоги з тест-кейсами, результатами і дефектами. Вона показує, що кожна вимога покрита, і допомагає оцінити вплив змін. У Jira я роблю це зв'язками між сторі, кейсами в Zephyr і багами.

Що має бути в тест-звіті?

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

Звіт пишеться для людей, які приймають рішення, тож головне — висновок і ризики, а не таблиці цифр.

На співбесіді: У звіті я показую, що і на якому білді тестували, результати виконання, відкриті дефекти за критичністю, ризики й непротестоване. І обов'язково чітку рекомендацію щодо релізу, бо звіт читають люди, які приймають рішення.

Як готувати тестові дані?

Покрити класи: валідні, невалідні, граничні, порожні, спецсимволи.
Мати різні типи користувачів: нові, з історією, заблоковані, з різними ролями й тарифами.
Створювати дані через API або SQL, а не вручну через UI — швидше й відтворювано.
Не використовувати реальні персональні дані — лише знеособлені або згенеровані.
Документувати, де лежать і як відновити дані.

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

Тест-кейс vs чек-лист

Тест-кейс — детальний сценарій: передумови, кроки, тестові дані й очікуваний результат для кожного кроку. Чек-лист — короткий перелік того, що треба перевірити, без покрокового опису. Тест-кейс відтворюваний будь-ким, навіть новачком без знання продукту.

Чек-лист швидше писати й підтримувати, але результат залежить від досвіду виконавця. Тест-кейси обираю для критичного функціоналу, складної бізнес-логіки, регулятивних вимог і як основу для автоматизації. Чек-листи — для smoke, стабільних частин продукту, exploratory-сесій і коли вимоги часто змінюються.

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

Якісний тест-кейс

Базова структура: ID, назва, передумови, кроки, тестові дані, очікуваний результат, пріоритет і посилання на вимогу. Назва має бути короткою й описувати, що саме перевіряємо, наприклад «Логін з неправильним паролем показує помилку». Кожен тест-кейс перевіряє одну річ, щоб при падінні було одразу зрозуміло, що зламано.

Кроки атомарні та конкретні: не «ввести дані», а «ввести в поле Email значення test@mail.com». Очікуваний результат — вимірюваний і однозначний, без слів на кшталт «працює коректно». Тест-кейс має бути незалежним від інших і не залежати від порядку виконання.

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