Один артефакт замість тисячі слів: Гібридна Матриця як SSOT у тестуванні

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт, наш любий читач. Я Аня, Head of QA у невеликій, але динамічній продуктовій команді. Працювала і в сталих продуктах, і в динамічних стартапах, тож трошки розуміюся на веденні тестової документації. А ще я просуваю підхід есенціалізму в керуванні процесами.

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

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

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

Проблема починається з моменту, коли тест кейси перестають бути одним із можливих інструментів контролю і стають обов’язковим за замовчуванням. Бо реальність продуктів (особливо динамічних або стартапів) — далеко не така, як у підручниках.

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

Для стартового поштовху, візьмемо буквально кілька варіантів коли тест кейси починають перетворюватись з інструменту контролю на тягар

Продукт змінюється швидше, ніж документація:
Флоу переписуються, кроки змінюються, частина логіки зникає та ін.
У якийсь момент QA починає витрачати більше часу на підтримку існуючих тест кейсів, ніж на створення чогось нового.

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

Стартапи, на початку яких тест кейси це зайві рухи:
Коли новий продукт стартує, то як правило, це мінімум людей і мінімум часу. А також невідомість «попливе чи нє». Відповідно вкладатися в такий об’єм бюрократії недоцільно, особливо якщо команда тестування менша за сам об’єм тестування.

Цих кількох прикладів нам достатньо для формування висновку, що наша форма контролю якості має відповідати реальним умовам продукту.

Можливо ти спитаєш, а як тоді рахувати те покриття, якщо не вести тест кейси? А яким чином тоді показувати прогрес? Або як же менеджеру зрозуміти, що QA щось робить?

Це абсолютно логічні та справедливі питання, бо справді, тест кейси часто використовують як інструмент видимості тому що:

• ними можна порахувати активність
• можна доводити покриття
• по них можна побудувати відсотки
• ними зручно звітувати

Але ж ми знаємо що:

Саме на цій ноті ми і почнемо обговорення альтернативних можливостей. Ми разом побудуємо просту порівняльну «Градацію Економічності» для предметного порівняння користі/витрат. Але перш ніж ми почнемо це робити, я перерахую «учасників» нашого порівняння.

Візьмемо ось ці альтернативні моделі форм контролю:

Mind Maps: Візуалізація функціоналу, де кожен вузол — це фіча або сценарій.

Checklists: Списки «що перевірити» без деталізації «як».

Session-Based Testing (SBT): Структурований підхід до дослідницького тестування в межах часових блоків.

Test Tours: Дослідження продукту через заздалегідь задану «лінзу» (роль, сценарій або намір користувача).

Acceptance Criteria (AC) Testing: Тестування напряму по критеріях прийняття, які прописані в Jira-тікетах.

⚠️ Це не універсальні цифри, а відносна оцінка з практики, щоб порівняти підходи між собою
⚠️ В розрахунках виходимо з того що у нас всюди належне виконання умов

Коротко поясню звідки я натикала цих значень і почнемо наш розгляд з «переможця»:

Acceptance Criteria. Ми не створюємо нові артефакти, а просто беремо те, що вже написав PM/BA, і використовуємо це як основу. Відповідно на створення та підтримку ми майже не витрачаємося.

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

Session-Based Testing. Жодних детальних кроків, тільки фокус на ризиках. По більшій мірі витрачаємося лише на написання Чартера (цілі) і на дебрифінг (звіт).

Mind Maps. Тут вже починаються витрати на створення та підтримку. Редагувати легко — просто перетягуючи гілки, але це все витрати.

Checklists. У цієї моделі повноцінні витрати на створення та підтримку, тому вона вже виходить витратною, але при цьому все одно вигідніша, тому що деталізація зовсім іншого рівня.

Ось так ми і прийшли до основної мети цієї статті. Ділюся з тобою своїм варіаном альтернативної моделі котру я собі побудувала під свої умови буття

Гібридна Матриця Покриття

Чому саме вона? Вона ж не економна?
Зараз ми разом її детально розберемо і я поступово поясню свій «важкий» вибір.
Для початку коротко поясню набір умов які породили цей гібрид:

• супер-динамічний продукт
• невелика команда
• використання АБтестів
• фактична неможливість вкладатися в бюрократію

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

З чого складається мій пазл:

Першим в таблиці описаний Еталонний позитивний ТК — це наш Blueprint.
Детальний опис основного сценарію (Happy Path) з усіма кроками та очікуваними результатами для кожного ключового етапу. Також можна скріни, лінки додати (що завгодно що максимально широко пояснить проходження ідеального флоу).
Його ми використовуємо для того, щоб побачити як має працювати флоу.

Наступним в таблиці замальовано Блок «Валідні дані».
Централізований збір валідних тестових даних якими будемо оперувати протягом роботи з матрицею. Тут думаю зрозуміло, відкриті тестові дані для того, щоб не витрачати час на їх створення і не множити непотрібних даних.

Оскільки за стандартами тестування першим проводиться позитивне функціональне тестування, ми далі в таблиці прописуємо Positive Flow. Це наша матриця покриття всіх необхідних варіацій. Простими словами — комбінації перевірок нашого Happy Path.

Відповідно, наступним кроком я описую блок Negative Flow. Ця об’ємна і відповідальна роль, тому що цей блок у нас відповідає за два фактори — перевірку валідації та «офіційне джерело» вимог до фічі.

І останні деталі це дані по виконанню:

• Status Auto/Manual: Візуальний контроль поточного покриття.
• Test Link: Прямий зв’язок з автотестами (CI/CD).
• Bug Link: Трейсабіліті дефектів прямо в документі.

Тут ми вже можемо трошки підсумувати, що ця матриця являється Single Source of Truth, тому нею в різних перерахованих вище цілях можуть користуватися QA, Dev, Lead та навіть PM.

Думаю тепер вже зрозуміліше чому я обрала такий коштовний шлях?

Продовжуючи свою розповідь додам, що не дивлячись на те що наша матриця, як МакКава 3*1, вона все одно коректно працює з метриками.
Ось основний перелік працюючих метрик які добре показують дієздатність матриці:

• Matrix Leakage Rate — кількість багів, знайдених на проді або після релізу, які мали бути закриті цією матрицею.
• Intersection Coverage (Cell %) — відсоток фактично перевірених перетинів від загального обсягу матриці. Показує загальний прогрес.
• Critical Path Density — % покриття найбільш ризикових зон (high-risk intersections).
• Maintenance Index — час на оновлення матриці при зміні вимог.
• Defect Spotting Ratio (DDR) — кількість багів на одну клітинку матриці. Може показати проблемні зони.
• Visibility of «White Spots» — відсоток «Not taken» від загальної кількості сценаріїв у матриці.
• Test Design Automation Coverage — показує, який відсоток вже покрито автотестами.

Тепер відкриваю останній козир — використання AI-інструментів для підтримки.

Для створення та оновлення такої матриці я використовую комбінацію Cursor та MCP-інструментів (звісно можна і інші тули брати, наприклад Claude).
Як це відбувається?
Агент аналізує код, зміни в pull request’ах і контекст Jira-тікетів, після чого пропонує оновлення структури матриці, сценаріїв або статусів покриття.

На моїй стороні залишається лише перевірити результат.
У результаті витрати на створення та підтримку такого артефакту зменшуються приблизно на 70–80%. Подібну матрицю можна зробити ± за годину, а оновити за ± 15 хвилин.

Саме цей козир переносить нашу матрицю в «Градації Економічності» на її почесне місце, оскільки створення і підтримка в таких умовах займають зовсім небагато часу і мінімум зусиль.

Ну що ж, настав час підсумків 🙂

Які я бачу плюси:

1. Single Source of Truth (SSOT).
Матриця об’єднує вимоги, мануальні перевірки та посилання на автотести в одному місці, зменшуючи кількість окремих артефактів і точок синхронізації.

2. Видимість і фокус на ризиках.
Замість перегляду сотень тест кейсів, матриця дозволяє за секунди побачити «червоні зони» через Intersection Coverage та Critical Path Density.

3. Економічність і масштабованість.
Завдяки відсутності детальних кроків і використанню AI-агентів, навантаження на створення та підтримку зменшується з ~50% до 15–20%, а зміни (нові браузери, девайси, варіації) додаються без болю.

4. Менше дублювання (Lean-ефект).
Нівелюється класичний ланцюжок «вимоги → ТК → автотест», де одна й та сама інформація може дублюватися кілька разів.

5. Синхронізація команди і Shift-Left.
Матриця працює як проста візуальна мова для QA, розробників і PM, дозволяючи починати роботу з покриттям ще на етапі грумінгу або дизайну

Мінуси я звісно теж виділяю:

1. Поріг входу: Для SBT або роботи з матрицею потрібна висока кваліфікація, джун може «загубитися» без детальних кроків.

2. Ризик «Мертвої таблиці»: Якщо закинути Maintenance Index, матриця перетвориться на такий самий «нечитабельний моноліт», як і Excel на 2000 рядків.

3. Залежність від культури: Погляд керівництва має вплив на підхід до бюрократії. І Matrix Leakage Rate може не допомогти в цьому.

• Бюджет: Використання АІ тулів потребує грошиків.
• Доступність: Використання АІ тулів напряму залежить від NDA правил компанії.
• Коли це НЕ працює: Така матриця це тупик для проектів з жорстким комплаєнсом (медицина, авіація, машинобудування тощо), де кожен крок має бути задокументований для аудиту.

Наостанок скажу, що тестування має допомагати деліверити, а не не просто обслуговувати процес.
Коли форма контролю якості починає коштувати дорожче за користь, її варто переглядати — незалежно від того, наскільки вона «канонічна».