Test Strategy

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

Він відповідає на запитання “як ми будемо тестувати?” і задає рамки для планування, виконання й управління тестуванням.

Мета Test Strategy

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

Основні складові Test Strategy

  1. Мета тестування
    • Чому ми тестуємо, які бізнес- або технічні цілі переслідуємо.
  2. Обсяг тестування (Scope)
    • Які функції, модулі або системи будуть протестовані, а які — ні.
  3. Рівні тестування
    • Unit, Integration, System, Acceptance тощо.
  4. Типи тестування
    • Функціональне, нефункціональне, регресійне, безпеки, продуктивності тощо.
  5. Підхід та методологія
    • Наприклад: ручне тестування, автоматизація, ризик-орієнтований підхід, Agile, DevOps.
  6. Критерії входу та виходу
    • Умови, за яких тестування може початися або завершитися.
  7. Інструменти та середовище
    • Які інструменти, фреймворки, середовища й дані використовуватимуться.
  8. Управління дефектами
    • Як реєструються, пріоритезуються та відслідковуються баги.
  9. Ролі та відповідальність
    • Хто за що відповідає в процесі тестування.
  10. Оцінка ризиків
    • Які потенційні ризики для якості продукту існують і як ними керувати.

Відмінність між Test Strategy і Test Plan

ПараметрTest StrategyTest Plan
РівеньВисокий (організаційний або проєктний)Детальний (для конкретного релізу або фази)
МетаВизначає загальні принципи тестуванняОписує конкретні дії й графік тестування
ЗмістПідхід, типи тестів, інструменти, ризикиОбсяг, ресурси, терміни, завдання
СтабільністьЗмінюється рідкоОновлюється частіше

Підсумки

Test Strategy = “Як ми тестуємо?”
Test Plan = “Що, коли і хто тестує?”

Impact Analysis Report

Impact Analysis Report — це звіт про аналіз впливу змін, який використовується в процесі тестування програмного забезпечення для оцінки того, які частини системи або тестів можуть бути зачеплені після внесення змін у код, вимоги чи дизайн.

Спрощено Impact Analysis Report допомагає зрозуміти:

  • що саме треба перевірити повторно після зміни
  •  і які модулі, тести чи документи можуть бути затронуті.

Основна мета Impact Analysis Report

  1. Оцінити наслідки змін — які частини ПЗ, тестів чи документації вплинуті.
  2. Мінімізувати ризики — уникнути пропущених дефектів після оновлення.
  3. Оптимізувати регресійне тестування — запускати лише релевантні тести.
  4. Покращити планування — оцінити обсяг роботи для тестування після змін.

Коли створюється Impact Analysis Report

  • Коли вимоги (BRD/SRS) оновлюються.
  • Коли змінюється код, модуль або API.
  • Коли виправляються дефекти (bug fixes).
  • Коли готується новий реліз або регресійне тестування.

Типовий зміст Impact Analysis Report

РозділОпис
1. Ідентифікація зміниЩо саме змінилося (номер вимоги, модуль, функціонал, Jira ticket і т.д.)
2. Причина зміниЧому зміни були внесені (нова вимога, виправлення дефекту, оптимізація тощо)
3. Затронуті області системиМодулі, компоненти, бази даних, API, UI-елементи, що можуть бути зачеплені
4. Вплив на тестуванняЯкі тест-кейси, сценарії, дані чи автоматизовані тести потрібно оновити або повторно запустити
5. Типи тестів, що потребують виконанняРегресійне, повторне (retesting), інтеграційне, приймальне
6. Ризики / зауваженняМожливі проблеми через зміну
7. Рекомендації / план дійЩо потрібно зробити далі (оновити RTM, тест-кейси, провести smoke/regression)

Приклад Impact Analysis Report

IDОпис зміниЗатронуті модуліПов’язані вимогиПов’язані тестиВпливДії
CHG-01Змінено логіку авторизації (додано 2FA)Login, SecurityBR-01, SRS-05TC-01, TC-02, TC-03ВисокийОновити тест-кейси, провести регресійне тестування
CHG-02Змінено API для переказів коштівPayments API, UI TransferBR-03TC-07, TC-08СереднійПовторне тестування API, smoke UI-тест
BUG-112Виправлено некоректне відображення балансуDashboardBR-02TC-05НизькийВиконати retest

Зв’язок із іншими артефактами

АртефактРоль у зв’язці
BRD / SRSВихідна база вимог, зміни в них тригерять аналіз впливу
RTM (Traceability Matrix)Допомагає знайти, які саме тести пов’язані з вимогою
Test PlanОновлюється після аналізу впливу
Regression Test SuiteФормується на основі результатів Impact Analysis

Переваги Impact Analysis Report

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

Risk Matrix

Risk Matrix (матриця ризиків) — це інструмент оцінки та управління ризиками у процесі тестування програмного забезпечення.

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

Спрощено Risk Matrix — це таблиця, яка показує, наскільки ймовірний ризик і наскільки серйозні його наслідки.

Її використовують, щоб зрозуміти:

  • що може піти не так
  • наскільки це небезпечно
  • що з цим робити.

Мета Risk Matrix у тестуванні

  1. Виявити потенційні проблеми заздалегідь
    (наприклад, відсутність середовища тестування, нестача часу, критичні дефекти).
  2. Оцінити пріоритети тестування — які області продукту мають найвищий ризик.
  3. Планувати тестування ефективніше, концентруючи зусилля на найбільш ризикових ділянках.
  4. Мінімізувати вплив ризиків через план дій або превентивні заходи.

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

Кожен ризик оцінюють за двома ключовими параметрами:

ПараметрПояснення
Ймовірність (Probability / Likelihood)Наскільки ймовірно, що ризик станеться (низька / середня / висока)
Вплив (Impact / Severity)Наскільки сильно ризик вплине на проєкт або продукт (низький / середній / високий)

Формула ризику

Рівень ризику = Ймовірність × Вплив

Приклад Risk Matrix (3×3)

Вплив / ЙмовірністьНизькаСередняВисока
ВисокийСередній ризикВисокий ризикВисокий ризик
СереднійНизький ризикСередній ризикВисокий ризик
НизькийНизький ризикНизький ризикСередній ризик

Високий — потрібно негайно керувати ризиком
Середній — контролювати, можливо, підготувати план дій
Низький — прийнятний ризик, не потребує додаткових дій

Приклад таблиці Risk Matrix

IDОпис ризикуЙмовірністьВпливРівень ризикуПлан дій / Мітгація
R1Затримка з тестовим середовищемВисокаВисокийВисокийПопросити DevOps підготувати резервне середовище
R2Недостатня документаціяСередняСереднійСереднійПровести уточнення вимог із BA (бізнес аналітик)
R3Відсутність досвіду команди з новим інструментомСередняВисокийВисокийПровести коротке навчання або парне тестування
R4Можливе перевантаження тестувальниківВисокаСереднійВисокийПерерозподіл завдань, найм додаткового QA
R5Незначні UI-баги у низькопріоритетних модуляхВисокаНизькийСереднійТестувати після основних модулів

Типи ризиків у тестуванні

КатегоріяПриклади
Проєктні ризикиЗатримки, брак ресурсів, неправильні оцінки часу
Технічні ризикиНові технології, складна інтеграція, нестабільне середовище
Бізнес-ризикиЗміна вимог, відмова клієнта від фіч
Ризики якостіВисока кількість дефектів, низьке покриття тестами
Ризики процесу тестуванняВідсутність тест-документації, автоматизації або даних

Переваги використання Risk Matrix

  • Дає чітку візуалізацію ризиків і їхнього впливу.
  • Допомагає пріоритезувати тестування — тестувати спочатку критичні області.
  • Підвищує прозорість для менеджерів і замовників.
  • Дозволяє завчасно планувати превентивні дії.

Testability Review Report

Testability Review Report — це звіт, який створюється під час аналізу вимог (Requirements Analysis) у процесі тестування програмного забезпечення.

Його мета — оцінити, наскільки вимоги до системи можна реально протестувати.

Спрощено Тestability Review Report — це документ, у якому тестувальники фіксують результати перевірки вимог на чіткість, повноту, узгодженість і можливість перевірки тестами.

Інакше кажучи, він відповідає на запитання:

  • Чи можемо ми це протестувати?
  • Чи зрозуміло, як перевірити, що вимога виконана?

Основна мета Testability Review Report

  1. Виявити неоднозначні або неперевірювані вимоги (наприклад, «система повинна бути зручною» — це суб’єктивно).
  2. Переконатися, що кожна вимога має чіткі критерії прийнятності.
  3. Допомогти бізнес-аналітикам і розробникам покращити якість вимог ще до початку розробки.
  4. Зменшити ризики помилок і переробок у подальших етапах.

Коли створюється

  • На ранньому етапі тестування життєвого циклу SDLC — одразу після отримання документів BRD / SRS.
  • Виконується під час фази “Requirement Analysis” у моделі V-Model або STLC (Software Testing Life Cycle).

Типовий зміст Testability Review Report

ID вимогиОпис вимогиПроблеми з тестуваннямРекомендаціїСтатус
1BR-01Система має бути швидкоюНемає чітких критеріїв швидкодіїВизначити максимальний час відгуку (наприклад, ≤3 сек)Needs Clarification
2BR-02Користувач може здійснювати переказ коштівВимога тестована (є чіткі вхідні та вихідні дані)Testable
3NFR-01Інтерфейс має бути інтуїтивно зрозумілимСуб’єктивна вимогаДодати метрику usability (наприклад, 90% користувачів виконують дію ≤5 сек)Needs Update

Основні критерії тестованості вимог

Щоб вимога вважалася тестованою, вона має бути:

КритерійПояснення
Чітка (Clear)Без двозначностей або суб’єктивних термінів («зручно», «швидко», «гарно»)
Однозначна (Unambiguous)Тлумачиться однаково всіма учасниками
Повна (Complete)Має всі необхідні деталі для створення тестів
Перевірювана (Verifiable)Можна об’єктивно підтвердити результат тестування
Реалістична (Feasible)Її можна протестувати з наявними ресурсами й інструментами

Формат документа

Testability Review Report може бути створений у вигляді:

  • Excel-таблиці з вимогами й коментарями тестувальників;
  • Confluence-сторінки із зазначенням статусу кожної вимоги;
  • або як офіційний звіт QA-команди, який додається до артефактів тестового процесу.

Requirements Traceability Matrix

Requirements Traceability Matrix (RTM) — це матриця трасування вимог, тобто спеціальна таблиця, яка пов’язує вимоги з відповідними тестами (а іноді й з дефектами).

У контексті тестування ПЗ RTM — це інструмент контролю повноти тестування, який дозволяє переконатися, що всі вимоги замовника перевірені хоча б одним тест-кейсом.

Простіше кажучи:

RTM — це документ, який допомагає відповісти на запитання: «Чи протестували ми все, що було потрібно?»

Основна мета RTM

  1. Забезпечити повне покриття вимог тестами
    (жодна вимога не залишилася неперевіреною)
  2. Відстежувати зміни у вимогах
    (якщо вимога змінюється — легко зрозуміти, які тести потрібно оновити)
  3. Підвищити прозорість і контроль якості
    (менеджери, тестувальники й замовники бачать зв’язок між вимогами, тестами та дефектами)

Типова структура RTM

ID вимогиОпис вимогиДжерело (BRD/SRS)ID тест-кейсуСтатус тестуПримітки
BR-01Авторизація користувачаBRD v1.2TC-01, TC-02Passed
BR-02Перегляд балансуBRD v1.2TC-03FailedВідображається некоректна сума
BR-03Переказ коштівBRD v1.2TC-04, TC-05In Progress
NFR-01Час відгуку < 3 секSRS v1.4TC-06PassedНефункціональна вимога

Роль RTM у тестуванні

Тестувальники використовують RTM для:

  • Перевірки покриття — чи всі вимоги BRD/SRS мають тест-кейси.
  • Відстеження дефектів — якщо тест не пройшов, можна відразу побачити, яку вимогу це стосується.
  • Регресійного тестування — легко знайти, які тести потрібно оновити при зміні вимоги.
  • Звітування — менеджери QA можуть швидко оцінити готовність проєкту до релізу.

Типи трасування

Тип трасуванняОпис
Forward TraceabilityВід вимог → до тестів (чи всі вимоги протестовані)
Backward TraceabilityВід тестів → до вимог (чи всі тести мають сенс і перевіряють реальні вимоги)
Bi-directional TraceabilityУ два боки — забезпечує повний контроль над змінами

Формат RTM

RTM може бути:

  • у вигляді Excel / Google Sheets;
  • у Jira / TestRail / Zephyr як звіт;
  • у Confluence у вигляді таблиці.