Тест-план у процесах тестування

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

👉Почнемо з тест-плану, бо він локальніший і його пишуть частіше за тестову стратегію.

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

Але найважливіше, знаючи усе це, задатися питанням: а навіщо пишуть тест-план?

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

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

✅ Таблиця редагувань/версій додається, якщо в документі, а отже і в розробці, очікується динаміка — нові скоупи, зміни вимог, розгалуження тощо. Це зручний елемент, що дозволить одразу пересвідчитися у (не)актуальності документу, почитати коментарі до змін і пінганути за необхідності автора нової версії.

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

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

✅ Скоуп, тобто які саме функціональні частини буде протестовано, варто прописувати завжди, навіть якщо передбачається, що треба тестувати все. Це просто зекономить час та допоможе уникнути непорозумінь. Окрім частин, що тестуються, він також може містити уточнення, які частини не буде протестовано.

✅ Типи тестування та підходи — це також корисна нотатка, навіть якщо усе доволі дефолтно. Звірятися з цим пунктом під час тестування зручно і приємно через подолання відчуття, наче щось було пропущено. Крім того, тут зазвичай наводиться певна аргументація, що для менш кваліфікованих співробітників може бути цінним джерелом практичних знань і досвіду.

✅ Розділ про ідентифіковані проблеми та ризики варто писати лише за умови, що стратегії з мітигації чи то просто профілактичні методи справді буде впроваджено. Проформенний рапорт типу “так, ми знаємо, що ми неідеальні”, який далі його написання не піде, лише заб’є тест-план надлишковою інформацією.

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

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

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

✅ Розділ із тестовою командою прописується, якщо на проєкті працюватиме одразу кілька QA. Варто одразу розподілити зони відповідальності та домовитися про регламент взаємодії (наприклад, акаунти, тестова документація, перехресна перевірка тощо). Під час роботи над помилками також зручно звертатися до цього розділу.

✅ Розклад потребує роботи із клієнтом у форматі чітких часових меж (а не, скажімо, вимог до об’єму людиногодин без конкретних термінів). Оперувати ним буває проблематично через динамічні зміни у вимогах і скоупах. Якщо цей розділ постійно переписується і зважати на нього немає змоги чи потреби, то й сам розділ можна опустити.

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

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

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