Рано-вранці вас будить дзвінок телефону. Берете слухавку — і чуєте голос найкращого друга, який каже, що хоче зробити сюрприз і вже десь о другій дня завітає в гості. Ви щиро раді, але через брак часу розумієте: накрити великий стіл до цього часу не встигнете, та й грошей не так багато, як хотілося б.
Звісно, ви починаєте пригадувати — що саме вашому другу смакує найбільше, які напої він полюбляє, — щоб і друг лишився задоволеним, і ви вклалися у час та бюджет.
Схожі ситуації трапляються й у сфері тестування програмного забезпечення. Дуже часто потреби бізнесу ставлять нас у жорсткі рамки часу й бюджету. «Протестувати на вчора» — це не просто слова, а реалія. Бо в конкурентів з'явилася нова фіча, яка дає переваги; або вчора зарелізований функціонал не задовольнив кінцевих користувачів, і на форумах та в соцмережах уже негативні відгуки — треба терміново реагувати. Або розробка нової фічі зайняла два тижні замість двох днів за оцінкою, а строки релізу посунути неможливо — бо вже запущено маркетингову кампанію із залучення нових клієнтів саме через новий функціонал.
ТО ЩО Ж QA-ІНЖЕНЕРУ РОБИТИ В ТАКІЙ СИТУАЦІЇ?
Перше, що допоможе, — це правило, коріння якого лежить у роботі італійського математика та економіста Вільфредо Парето, зробленій ще у XIX столітті. Він вивів закономірність: 80% наслідків залежать від 20% причин. Ця закономірність працює в багатьох сферах нашого життя — і сфера тестування програмного забезпечення не є винятком.
Що ж це означає для QA-інженера? А означає це те, що варто приділяти 20% свого часу на перевірку 80% найважливіших сценаріїв. Таким чином, можна забезпечити 80% покриття тестами за 20% часу. Звісно, цифри можуть бути й іншими — головне зрозуміти саму ідею.
Вона полягає в тому, що ми маємо приділяти час найважливішим сценаріям, а не всім поспіль. То як знайти ті самі 20% тестів, які покриють 80% критичних ризиків?
Підхід 1 — Risk-Based Testing (Тестування на основі ризиків)
Коли часу обмаль, найкращий друг QA — матриця ризиків. Кожна фіча чи сценарій оцінюється за двома критеріями:
- Ймовірність відмови (Probability): Наскільки складний цей код? Чи зачіпає він «крихку» архітектуру системи? Чи писав його новий розробник?
- Вплив на бізнес (Impact): Що станеться, якщо ця функція зламається? Компанія втратить гроші? Користувач не зможе увійти в додаток?
Правило: Тестуємо лише те, що потрапляє в зону «Висока ймовірність + Високий вплив». Другорядні інтерфейсні баги (UI-нотифікації, друкарські помилки, колір кнопок) свідомо ігноруються до наступної версії.
Рівень ризику = Вплив (Impact) × Ймовірність збою (Likelihood)
| ПРІОРИТЕТ | КРИТЕРІЇ | ЩО ТЕСТУЄМО |
|---|---|---|
| P0 — Критичний | Падіння сервісу, втрата грошей або даних, блокування ключових флоу (реєстрація, оплата, логін) | Тестувати обов'язково (Smoke + Happy Path головних фіч) |
| P1 — Високий | Не працює важлива функція, але є обхідний шлях (workaround), або функція зачіпає значну частину користувачів | Тестувати за наявності часу (основні негативні сценарії) |
| P2 — Середній / Низький | Візуальні баги, рідкісні edge cases, незручності в UI | Свідомо пропускати / відкладати в беклог |
Підхід 2 — Перевірка критичних шляхів користувача
Критичний шлях — це основна послідовність дій, заради якої користувач взагалі відкриває ваш продукт.
- В інтернет-магазині це: Пошук товару → Додавання в кошик → Оплата (Checkout).
- У банкінгу: Авторизація → Переказ коштів → Перевірка балансу.
Якщо не працює сторінка «Про нас» — це неприємно. Якщо користувач не може заплатити — це катастрофа. Завжди фокусуйтеся на End-to-End (E2E) сценаріях, які приносять бізнесу цінність. В умовах обмеження часу й ресурсів окрему увагу приділяємо саме тому, що дійсно важливо користувачам і бізнесу.
Підхід 3 — Аналіз історичних «точок болю»
Згідно з принципами ISTQB, дефекти схильні накопичуватися в одних і тих самих місцях. QA знає свій проєкт: якщо модуль інтеграції з платіжною системою або генерація звітів раніше давала збої — перевірку варто починати саме з них.
Рекомендуємо курси по темі
Підхід 4 — Мінімізація регресії: Smoke і Sanity
Замість повної перевірки всього, що функціонувало раніше, фокусуємося на двох рівнях:
- Smoke testing («Димний» тест) — перевірка того, що білд взагалі запускається, основні модулі відповідають, а додаток не падає в перші секунди роботи.
- Sanity testing («Перевірка відповідності») — глибока, фокусна перевірка конкретної ділянки системи, яка зазнала змін, та її найближчих залежностей.
Підхід 5 — Чек-листи й дослідницьке тестування
В умовах обмеженого часу треба відкласти детальне написання й вичитування покрокових тест-кейсів. Тут ефективні два інструменти:
- Чек-листи — високорівневі списки перевірок (без кроків типу «натисни сюди»), які тримають фокус на ключових перевірках.
- Дослідницьке тестування (Exploratory Testing) — QA одночасно вивчає систему та розробляє тести на ходу, спираючись на свій досвід.
Чек-лист дозволяє охопити більше функціональних областей за менший час, тоді як дослідницьке тестування допомагає виявити неочевидні проблеми, які неможливо знайти за допомогою формальних тест-кейсів. Важливо пам'ятати: незважаючи на швидкість, тестування має бути ретельним й охоплювати всі критично важливі аспекти роботи продукту.
Рекомендуємо публікації по темі
ПРАКТИЧНІ ПОРАДИ: ЩО РОБИТИ QA В УМОВАХ АВРАЛУ
☐ Запитати в ліда розробки: «Які саме файли/модулі ви зачепили?» (звужує зону регресії)
☐ Перевірити авторизацію і реєстрацію (головні ворота)
☐ Пройти основним «грошовим» шляхом клієнта
☐ Перевірити поведінку на граничних значеннях (Boundary Values) лише у критичних полях
☐ Зарепортувати знайдені баги безпосередньо розробнику в чат, мінімізуючи бюрократію в Jira
Коли часу немає, завдання QA — не знайти всі баги (бо вичерпне тестування неможливе), а надати команді об'єктивну впевненість, що продукт виконає свою основну функцію, а бізнес не зазнає репутаційних чи фінансових втрат. Наша зброя в таких випадках — це розуміння бізнес-логіки продукту, найважливіших шляхів користувача й логіки побудови системи, яку ми тестуємо.
І наостанок: коли пізніше з'явиться час — завдання тестувальника взяти здобуті під час авралу результати та акуратно інтегрувати їх у вже існуючий флоу тестування проєкту: дописати, де треба, нові тест-кейси; актуалізувати автотести; завести ті дефекти, які було проігноровано, та проконтролювати їх виправлення.
То якщо ви все зробите вірно, то неочікуваний візит друга принесе йому та вам лише задоволення. А в кінці дня ви зможете подивитися на годинник і сказати собі: «Так, сьогодні було спекотно, але я впорався».
Рекомендуємо публікації по темі
