Ризик-орієнтоване тестування

Що таке ризик у тестуванні і чим він відрізняється від дефекту?

Ризик (risk) — потенційна подія або умова з негативними наслідками в майбутньому; ключове слово — «потенційна», бо ризик існує до того, як щось зламалося. «Платіжний модуль переписали на нового провайдера, там можуть бути дефекти» — це ризик; «оплата карткою падає з помилкою 500» — уже дефект: ризик реалізувався. Тому ризиками керують до і під час тестування, а severity виставляють уже знайденому дефекту за фактом. Плутати ризик із severity — типова помилка: severity — атрибут наявної проблеми, ризик — оцінка майбутньої. Практичний наслідок: питання «які ризики цієї фічі» — про те, що може піти не так, а не про список відомих багів.

З чого складається ризик і як визначають його рівень?

Атрибути два: ймовірність (likelihood) — наскільки реально, що подія станеться, і вплив (impact) — наскільки боляче буде, якщо станеться. Ймовірність завжди між нулем і одиницею: неможлива подія — не ризик, а та, що вже сталася, — не ризик, а проблема. Вплив міряють через гроші, користувачів, репутацію і юридичні наслідки. Разом атрибути дають рівень ризику (risk level), який на практиці часто рахують як добуток: рівень = ймовірність × вплив. Саме рівень визначає, скільки уваги тестування приділить конкретній зоні продукту, — і це готова аргументація на питання «чому ти тестуєш саме це і саме так».

Чим продуктовий ризик відрізняється від проєктного? Наведи приклади.

Продуктовий ризик (product risk) — про якість самого продукту: некоректний розрахунок знижки, втрата даних при міграції, вразливість в авторизації; його відчують користувач і бізнес після релізу. Проєктний ризик (project risk) — про хід проєкту: ключовий розробник звільнився, тестовий стенд не готовий, вимоги запізнюються; це болить команді до релізу. Головна різниця — хто з ними працює: продуктові ризики знижує тестування, спрямовуючи перевірки саме туди, де ризик; проєктні тестування не «лікує» — це зона менеджменту, планування й комунікації. Продуктові ризики ще називають ризиками якості (quality risks), і саме з ними працює risk-based testing. Класичний провал на співбесіді: на питання про продуктові ризики платіжної фічі відповісти «може не вистачити часу на тестування» — брак часу проєктний, а «спишуться гроші не з тієї картки» — продуктовий.

Що таке ризик-орієнтоване тестування і яку проблему воно розв'язує?

Ризик-орієнтоване тестування (risk-based testing) — підхід, у якому порядок, глибина, обсяг і форма перевірок визначаються рівнем продуктового ризику: тестуємо насамперед там, де відмова найімовірніша і найболючіша. Проблема, яку він розвʼязує, фундаментальна: вичерпне тестування неможливе, тож будь-який тестувальник і так щось пріоритизує — питання лише, робить він це неявно «за інтуїцією» чи явно й аргументовано. Risk-based робить вибір прозорим і зрозумілим для бізнесу: рішення «цю зону глибоко, ту по верхах, он ту свідомо пропускаємо» зафіксоване і пояснюване. Різниця між джуном і сеньйором не в тому, чи він вибирає, а в тому, чи може пояснити свій вибір.

Керування ризиками — разова вправа на старті проєкту?

Ні, це цикл: ідентифікація (що може піти не так) → оцінювання (ймовірність × вплив) → зменшення (тестування, ревʼю, фіче-флаги) → моніторинг (нові дані з прогонів і проду) — і знову по колу, бо кожен реліз змінює картину. Новий провайдер, переписаний модуль, свіжа статистика дефектів змінюють і ймовірності, і впливи. Матриця, складена пів року тому й не переглянута, описує неіснуючий продукт. Практично це означає: оцінку ризиків повторюють під кожен помітний реліз, а моніторинг повертає в неї факти — де реально падало на прогонах і в проді.

Звідки брати список ризиків і чому його не варто складати наодинці?

Джерела ідентифікації: вимоги і user story, архітектурні зміни, історія дефектів, скарги користувачів, досвід команди. Оцінка ризиків — крос-функційна робота: розробник знає, де код складний і де він «різав кути», продакт — яка фіча приносить гроші, підтримка — на що скаржаться користувачі. Матриця, складена одним тестувальником наодинці, систематично зміщена: без розробника не видно реальної складності коду, без продакта — реальної ціни відмови. Тому навіть 30-хвилинна спільна сесія оцінювання дає точнішу картину, ніж одноосібна таблиця.

Які фактори підвищують ймовірність відмови, а які — вплив?

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

Що таке матриця ризиків і як команда нею користується?

Матриця ризиків — таблиця «ймовірність на вплив»; у робочому мінімумі вистачає шкали з трьох значень по кожній осі. Кут «висока ймовірність × високий вплив» — критичний: тестується першим, найглибше і бажано з автоматизованою регресією; протилежний кут — мінімальний: чеклист по happy path або свідома відмова від тестування. Точні числа не головне — головне ранжування і домовленість команди, що означає кожен рівень. Важливий нюанс: «свідомо не тестуємо» — це зафіксоване рішення, про яке бізнес знає, а не мовчазний пропуск. Живий приклад: чекаут на новому платіжному провайдері (новий код плюс гроші) — критичний кут, вибір аватарки в профілі (простий ізольований код, косметичний наслідок) — мінімальний.

На які практичні рішення впливає рівень ризику?

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

Risk-based testing — це спосіб тестувати менше й економити?

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

Реліз завтра, повна регресія займає три дні, у тебе чотири години. Що робитимеш?

Ріжу обсяг за ризиком, ярусами. Перший — смоук критичних бізнес-потоків (гроші, дані, вхід) незалежно від того, що змінювалось: якщо зламано вхід чи оплату, решта не має значення. Другий — зони, зачеплені змінами релізу: за пул-реквестами, тікетами й розмовою з розробниками визначаю зачеплені модулі й регресую навколо них — це аналіз впливу змін (impact analysis). Третій — історично крихкі місця: принцип скупчення дефектів, де падало раніше — впаде знову. Четвертий ярус чесно ріжеться за залишком часу. І обовʼязкова частина, яку кандидати губляться сказати: зрізаний обсяг — рішення, яке озвучується: «встиг перевірити X і Y, поза обсягом лишилось Z, ризик такий-то», інакше менеджмент вважає, що регресія була повною. Відповідь «прогоню найважливіше» без критерію найважливішого — провал: інтервʼюер дивиться саме на структуру пріоритизації.

Як рівень ризику використовують в автоматизованій регресії?

Тегами за рівнем ризику зони, яку перевіряє тест: критичні сценарії позначаються, наприклад, @critical, другорядні — @low. Тоді зрізаний прогін за браку часу — одна команда: npx playwright test --grep @critical. Це прямий переклад матриці ризиків у виконуваний артефакт: пріоритизація, про яку домовились на папері, стає фільтром пайплайна. Побічний бонус — той самий зріз працює як швидкий смоук білда без повного прогону.

Хто ухвалює рішення про реліз і яка роль QA?

Рішення ухвалює бізнес; тестування постачає інформацію для рішення, але не ухвалює його. QA не «дозволяє» і не «забороняє» реліз, бо не володіє всією картиною: вартість затримки, обіцянки клієнтам, конкуренти. Зате QA — єдиний, хто може чесно описати залишковий ризик (residual risk): що не перевірено, які дефекти лишилися відкритими і чим це загрожує. Це питання-пастка на зрілість: інтервʼюер відсіює кандидатів, які бачать QA «воротарем» релізу. Команда, де QA «не пускає» релізи, отримує війну; команда, де QA дає картину ризиків, — усвідомлені рішення.

Що має бути у звіті QA перед релізом?

Відповіді на три питання. Перше: що перевірено і з яким результатом — чи зелені критичні потоки. Друге: що НЕ перевірено і чому (не встигли, не було середовища) — і який там потенційний вплив. Третє: які відомі дефекти їдуть у реліз — із severity й обхідними шляхами. Разом це і є опис залишкового ризику: бізнес бачить не «pass rate 82%», а конкретну картину — що лишилося непокритим і чим це загрожує. Без другого пункту звіт бреше замовчуванням: усе неперевірене виглядає як безпечне.

Усі критерії виходу виконано. Чи означає це, що реліз готовий?

Не обовʼязково: критерії виходу (exit criteria) — індикатор, а не автомат. Буває, що формальні критерії на кшталт «100% критичних кейсів пройдено, нуль відкритих дефектів severity critical» виконано, а релізити не можна — щойно знайшли підозрілу поведінку в оплаті. І навпаки: критерії провалено, а бізнес релізить, бо вартість затримки вища за залишковий ризик, — і це легітимне рішення, якщо ухвалене усвідомлено. Критерії структурують розмову про готовність, але не замінюють її. Роль QA — щоб рішення в обидва боки спиралося на чесну картину ризиків, а не на саму галочку в тест-плані.

Чи є тестування єдиним способом знизити ризик?

Ні. Тестування працює з ризиком до релізу, але є ціла група механізмів, які зменшують вплив відмови вже після нього: фіче-флаг (вимкнути фічу за секунду без релізу), поступове розкочування на відсоток користувачів, моніторинг і алерти, готовий план відкату. Іноді «релізимо під флагом на 5% користувачів з алертом на помилки оплати» — краще рішення, ніж «ще тиждень тестуємо». Сеньйорська відповідь тримає в голові весь арсенал і пропонує комбінацію, а не тільки «дайте більше часу на тести».

Менеджер каже: «часу на тестування немає, релізимо». Твої дії?

Перекладаю технічний стан на мову наслідків для бізнесу і приношу варіанти з цінами, а не вето. Формула: сценарій відмови → хто і як постраждає → що пропоную; кожен елемент конкретний — не «можуть бути проблеми», а «промокод застосується двічі»; не «користувачам буде погано», а «кожне замовлення з промокодом — мінус 20% до маржі». Далі варіанти: (а) зсунути реліз на два дні й закрити дефекти оплати; (б) релізити вчасно, але промокоди під фіче-флагом вимкнено до фіксу; (в) релізити як є, прийняти ризик подвійних знижок і моніторити суми замовлень. «Релізити не можна» — глухий кут, після якого QA виглядає гальмом; варіанти з цінами лишають рішення за бізнесом, але роблять його усвідомленим. Аргументи виду «47 багів і pass rate 82%» не працюють, бо для бізнесу це шум: не зрозуміло, страшно це чи ні.

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

Кейс 1. Матриця ризиків на реліз: чотири зміни, одна таблиця

Реліз інтернет-магазину, у ньому чотири зміни. Часу на «перевірити все однаково глибоко» немає — і не мало бути. Сідаємо з розробником і продактом на пів години й розкладаємо кожну зміну за двома осями.

Що дивитися і чому:

• Оцінки в колонках — не з голови тестувальника. «Код новий» і «даних багато» сказав розробник, «гроші кожного замовлення» і «мінус до маржі» — продакт. Матриця, складена наодинці, систематично зміщена: без розробника не видно складності коду, без продакта — ціни відмови.
• Рівень керує не лише порядком, а й технікою. Для критичного чекаута — таблиця рішень і негативні сценарії; для аватарки — чеклист. Однакова глибина скрізь означала б, що аватарка вкраде час у грошей.
• Ймовірність і вплив — незалежні осі. Міграція не «новіша» за чекаут, але її вплив тягне рівень угору через незворотність: якщо дані замовлень зіпсуються, «перевикотити» їх не вийде. Тому в рішенні зʼявляється план відкату — зменшення впливу, а не тільки перевірки.
• «Мінімальний» — теж рішення, і воно зафіксоване. У таблиці явно написано, що аватарка отримує один прохід. Бізнес це бачить і не здивується; мовчазний пропуск без сліду в таблиці — уже не risk-based, а лотерея.
• Матриця живе до наступного релізу. Якщо провайдер відпрацює три релізи без дефектів, його ймовірність поповзе вниз; якщо на проді спливе баг у знижках — угору. Таблиця без перегляду за пів року описує неіснуючий продукт.

Кейс 2. Чотири години замість трьох днів: як різати регресію

Реліз завтра вранці, повна регресія займає три дні, у розпорядженні — чотири години. Погана відповідь — прогнати скільки встигнеться з початку списку тест-кейсів. Хороша — розкласти час за ярусами ризику.

В автоматизованій регресії та сама матриця вшита тегами — рівень ризику зони прямо в назві теста:

// Тег = рівень ризику зони, яку перевіряє тест
test('оплата карткою списує кошти і створює замовлення @critical', async ({ page }) => {
  // ...
});

test('промокод застосовується до підсумку один раз @medium', async ({ page }) => {
  // ...
});

test('зміна аватарки оновлює фото в профілі @low', async ({ page }) => {
  // ...
});

# 4 години: тільки критичний зріз
npx playwright test --grep @critical

# трохи більше часу — розширюємо до середнього рівня
npx playwright test --grep "@critical|@medium"

Останній обовʼязковий крок — звіт про зрізаний обсяг, коротке повідомлення менеджеру й команді:

Регресію зрізано з 3 днів до 4 годин за ризиком.
Перевірено: смоук критичних потоків — зелений; чекаут з новим
провайдером — 14 сценаріїв, 1 дефект (неправильний текст помилки
при відхиленій картці, severity minor).
Поза обсягом: повна регресія особистого кабінету та email-нотифікацій.
Ризик: можливі дефекти в некритичних потоках, гроші й дані не зачіпають.

Що дивитися і чому:

• Перший ярус не залежить від того, що змінювалось. Регресія існує, бо зміни ламають неочікувані місця; смоук грошей і входу — страховка від «зламали там, куди ніхто не дивився».
• Другий ярус будується з фактів, а не інтуїції. Перелік пул-реквестів і пряме питання розробникам «які модулі зачеплено?» дає карту для регресії навколо змін — це і є impact analysis у польових умовах.
• Теги перетворюють домовленість на артефакт. Пріоритизація з матриці стає однією командою --grep — і зрізаний прогін відтворюваний, а не «я щось повибирав руками».
• Без звіту зрізана регресія виглядає як повна. Менеджмент за замовчуванням вважає, що «регресія пройдена» означає всю регресію. Формула «перевірено X, поза обсягом Z, ризик такий-то» знімає це замовчування.

Кейс 3. Переклад звіту про якість на мову бізнесу

П'ятниця, статус-мітинг перед релізом. У QA є цифри, у менеджменту — рішення, яке треба ухвалити. Ті самі факти можна подати двома мовами:

Що дивитися і чому:

• Формула лівої→правої колонки: сценарій відмови → хто і як постраждає → що пропоную. Кожен елемент конкретний: не «можуть бути проблеми», а «промокод застосується двічі»; не «буде погано», а «мінус 20% до маржі».
• Кількість багів і pass rate самі по собі рішення не дають. З «47 багів» незрозуміло, страшно це чи ні: усі 47 можуть бути про кривий відступ у футері — або два з них про списання грошей. Рішення ухвалюється за наслідками, а числові зрізи лишаються підтримкою.
• Вето — глухий кут, варіанти з цінами — розмова. Після «релізити не можна» QA виглядає гальмом, і рішення все одно ухвалять без нього. Три варіанти з явними цінами лишають рішення за бізнесом — але тепер воно усвідомлене, і залишковий ризик прийнятий явно, а не за замовчуванням.
• Варіант (б) — нагадування, що тестування не єдиний важіль. Фіче-флаг, розкочування на відсоток користувачів, моніторинг і план відкату зменшують вплив відмови вже після релізу — іноді це дешевше за тиждень додаткових перевірок.

Базові поняття

• Знаю означення ризику: потенційна подія з негативними наслідками — вона існує ДО того, як щось зламалося; коли зламалося — це вже дефект.
• Можу назвати два атрибути ризику — ймовірність (likelihood) і вплив (impact) — і пояснити, що рівень ризику часто рахують як їх добуток.
• Розумію різницю «ризик vs severity»: ризик — оцінка майбутньої відмови, severity — атрибут уже знайденого дефекту.
• Можу пояснити різницю продуктового і проєктного ризику, навести по два приклади і сказати, хто з кожною групою працює: продуктові знижує тестування, проєктні — менеджмент і планування.

Аналіз ризиків

• Знаю цикл керування ризиками: ідентифікація → оцінювання → зменшення → моніторинг — і що він крутиться з кожним релізом, а не разово на старті.
• Можу назвати джерела ідентифікації (вимоги, архітектурні зміни, історія дефектів, скарги, досвід команди) і пояснити, чому оцінка — крос-функційна вправа, а матриця одного тестувальника зміщена.
• Знаю фактори ймовірності (новий чи переписаний код, складна логіка, багато інтеграцій, історія дефектів, тиск строків, нова технологія) і фактори впливу (гроші в потоці, незворотність, масовість, юридичні наслідки, репутація).
• Можу накидати матрицю ризиків 3×3 і пояснити, що робити з критичним кутом (першим, найглибше, з автоматизованою регресією) і мінімальним (happy path або свідома відмова).

Ризик у рішеннях тестування

• Знаю чотири рішення, якими керує рівень ризику: порядок, глибина і техніка тест-дизайну, обсяг конфігурацій, форма перевірок.
• Можу пояснити, чому risk-based — перерозподіл тих самих зусиль, а не «тестувати менше»: якщо сумарна глибина просто впала, це секвестр.
• Розумію, що «свідомо не тестуємо» — зафіксоване рішення, про яке знає бізнес, а не мовчазний пропуск.

Регресія за браку часу

• Можу розкласти зрізану регресію за ярусами: смоук критичних бізнес-потоків → зони змін релізу → історично крихкі місця → решта за залишком.
• Знаю, що таке аналіз впливу змін (impact analysis) і звідки він береться: пул-реквести, тікети, розмова з розробниками про зачеплені модулі.
• Розумію, як теги за рівнем ризику (@critical, @low) перетворюють пріоритизацію на одну команду прогону через --grep.
• Памʼятаю: зрізаний обсяг обовʼязково озвучується — «перевірив X і Y, поза обсягом Z, ризик такий-то», інакше менеджмент вважає регресію повною.

Реліз і мова бізнесу

• Можу пояснити роль QA в релізі: описує залишковий ризик (residual risk), а рішення ухвалює бізнес — QA не «воротар».
• Знаю три питання доброго звіту перед релізом: що перевірено і з яким результатом, що НЕ перевірено і чому, які відомі дефекти їдуть у реліз.
• Розумію, чому критерії виходу — індикатор, а не автомат: виконані критерії не гарантують готовність, а провалені не завжди блокують реліз.
• Знаю нетестові способи знизити ризик: фіче-флаг, поступове розкочування на відсоток користувачів, моніторинг з алертами, план відкату.
• Володію формулою розмови з менеджментом: сценарій відмови → хто і як постраждає → варіанти з цінами замість вето.