Галина Чорнодуб QA Lead у Flawless, Викладач Комп'ютерної школи Hillel.

ТА САМА ІСТОРІЯ, ЧЕРЕЗ ЯКУ Я ЗРОЗУМІЛА, ЩО ТАКЕ BUG HUNTER MINDSET

На початку кар'єри я була початківцем і остерігалася зробити зайвий клік або щось зламати. Я виконувала тест-кейси поетапно, відзначала Passed і переходила до наступного завдання, як це роблять багато спеціалістів. Але один випадок усе змінив.

Це був один із моїх перших проєктів — медичний SaaS. Я оформлювала тестове замовлення відповідно до інструкції: натискала «Оформити», чекала, потім перевіряла результат у кабінеті. Одне замовлення. Passed. У певний момент сторінка зависла. Я натиснула кнопку ще раз, а потім ще кілька разів, усього п’ять разів.

Система відобразила лише одне замовлення. Однак через кілька днів у відділі підтримки виникли проблеми: клієнту зателефонували п’ять разів, а з картки списали кошти також п’ять разів. Я не шукала цей баг і навіть не знала терміна «race condition». Просто відхилилася від стандартного сценарію і зробила те, що зазвичай не рекомендується.

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

А ЩО МОЖНА БУЛО Б ЗРОБИТИ, ЩОБ ПЕРЕВІРИТИ ЦЕ СВІДОМО?

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

1. Перевірити поведінку кнопки під час навантаження

Відкрити Network, вибрати Slow 3G і подивитися:

Кнопка блокується після першого кліку?
Чи можна натиснути ще раз, поки спінер крутиться?

2. Перевірити, чи надходять запити. Перевірте у вкладці Network, скільки запитів надходить на бекенд. Якщо кожен клік створює новий запит, це є ознакою проблеми.

3. Перевірити в різних браузерах

Chrome, Firefox, Safari, мобільний браузер. Можливо, проблема тільки в одному.

4. Перевірити API напряму

Скопіюйте запит у форматі cURL і надішліть його кілька разів поспіль через Postman або в командній консолі. Якщо виникають дублікати, це проблема на бекенді.

5. Перевірити логи на бекенді

Якщо маєте доступ, перегляньте, скільки запитів надійшло за секунду і чи є однакові запити з однаковим session_id.

Покроковий сценарій: як би я діяла зараз

Відкриваю форму замовлення.
Відкриваю DevTools → Network.
Установлюю throttling: Slow 3G.
Натискаю «Оформити» один раз.
Чекаю 0,5 секунди й натискаю ще раз.
Дивлюсь у Network: скільки запитів пішло на бекенд?
Якщо два запити — перевіряю в базі даних: скільки замовлень. Якщо є дублікати, створюю баг-репорт із відео, логами та кроками для відтворення. Якісний баг-репорт містить чіткі кроки, фактичний і очікуваний результат, усю доступну інформацію, зокрема логи, скріншоти або відео, а також стислий опис. Це допомагає команді швидко зрозуміти й відтворити проблему без додаткових уточнень.

ЩО ЦЕ ДАЄ?

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

РИНОК ЗМІНИВСЯ

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

Якщо ви:

втомилися бути «галочкою» в Jira;
боїтеся, що вашу роботу автоматизують;
не знаєте, як відповідати на співбесіді на запитання «зламайте мені цей екран»;
отримуєте відмови, хоча «усе робите правильно»;

Ви не є поганим тестувальником. Просто ще не навчилися мислити по-іншому.

ЩО ТАКЕ BUG HUNTER MINDSET?

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

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

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

6 УСТАНОВОК BUG HUNTER MINDSET

1. Здорова підозрілість

Баг-хантера за замовчуванням не довіряти нікому: ні розробнику, який стверджує, що все працює, ні вимогам, ні навіть власному попередньому досвіду. Фраза «це ж очевидно» є однією з найнебезпечніших у тестуванні. Саме за очевидними речами часто приховуються критичні баги.

Розробник тестує свій код на позитивному сценарії, оскільки підсвідомо знає, як ним правильно користуватися. Ваше завдання — перевіряти нетипові способи використання продукту.

2. Цікавість і «а що, якщо?»

Це основний рушій такого мислення.

Перед вами форма реєстрації. Замість того, щоб просто ввести коректні дані, ви питаєте:

А що, якщо email без @?
А з двома @?
А якщо в полі імені — 5000 символів?
А емодзі?
А що, якщо двічі натиснути кнопку дуже швидко?
А якщо під час відправки форми вимкнути інтернет на півсекунди?

Кожне таке питання може виявити потенційний баг.

3. Емпатія в обидва боки

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

До зловмисника: розуміти, як систему можна використати проти неї. Наприклад, що станеться, якщо підставити чужий ID у посилання, змінити ціну в запиті до API або ввести '; DROP TABLE у поле пошуку?

4. Мислення межами

Помилки найчастіше виникають на межових значеннях. Це майже закономірність у розробці. Якщо поле приймає від 1 до 100 символів, найцікавіше відбувається при значеннях 0, 1, 100, 101 і 5000. Якщо є вікова перевірка 18+, тестуйте 17, 18 і 19.

Пам'ятаєте YouTube і Gangnam Style? Лічильник переглядів зберігався як 32-бітне число з максимальною межею 2,1 млрд. Ніхто не очікував, що відео набере стільки переглядів, але це сталося. YouTube досяг межі типу даних, яку ніхто не перевірив, і це стало глобальною проблемою.

5. Ламати щасливий шлях

Happy path — це сценарій, у якому все ідеально. Розробник його протестував. Він працює. Основна цінність полягає у перевірці відхилень від цього сценарію: перервати процес, змінити порядок дій, оновити сторінку під час оплати, закрити вкладку й повернутися, натиснути «Назад» після успішної транзакції.

Історія з п’ятьма замовленнями ілюструє це: один відхід від ідеального сценарію — і баг стає очевидним.

6. Розуміння архітектури

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

ІНСТРУМЕНТИ, ЯКІ ДОПОМАГАЮТЬ

Консоль браузера. Перевіряйте, чи можна обійти валідацію на фронті. Наприклад, вставити в консоль:

text
document.querySelector('input').value = 'test'
document.querySelector('.btn').click()

Вкладка Network. Перевіряйте, які дані фактично надсилаються на бекенд. Змінюйте параметри, наприклад, userId, і надсилайте запит повторно.

Throttling (Slow 3G). Імітуйте повільне інтернет-з’єднання. У таких умовах часто виникають баги з дублюванням і зависанням.

Burp Suite / OWASP ZAP. Перехоплюйте запити й змінюйте параметри — ціну, кількість, ID. Перевіряйте, чи перевіряє бекенд.

Мапи мислення (XMind / Miro). Малюйте структуру: позитивні, негативні, граничні й нестандартні сценарії. Це не тест-кейси, а гіпотези.

Запис екрана (Loom). Якщо ви виявили незвичайний баг, одразу робіть запис. Якщо розробник не зможе його відтворити, ви зможете надати відео.

Шпаргалка: 10 запитань «а що, якщо»

Я підготувала список запитань, які ставлю собі перед кожним тестуванням:

А що, якщо ввести значення, яке на 1 більше за максимальне?
А що, якщо ввести значення на 1 менше за мінімальне?
А що, якщо ввести порожнє поле?
А що, якщо ввести емодзі?
А що, якщо двічі дуже швидко натиснути кнопку?
А що, якщо натиснути «Назад» після успішної дії?
А що, якщо оновити сторінку під час надсилання форми?
А що, якщо вимкнути інтернет на півсекунди?
А що, якщо вставити текст із 5000 символів?
А що, якщо змінити ID у посиланні на чужий?

Коли ці питання стануть звичкою, ви почнете знаходити баги ще до початку тестування.

ЯК ТРЕНУВАТИ ЦЕ МИСЛЕННЯ

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

Ставте під сумнів вимоги. Звертайте увагу не лише на те, що зазначено, а й на те, чого бракує. Прогалини у вимогах часто є джерелом багів.
Вивчайте чужі баг-репорти: публічні баг-трекери, CVE, аналізи відомих збоїв сервісів, звіти з платформ bug bounty. Це дозволяє зрозуміти хід думок людей, які виявляли неочевидні вразливості.
Тестуйте негативні сценарії. На кожен позитивний сценарій має припадати кілька негативних: порожні поля, заборонені символи, перевищення лімітів, неправильні формати. Звертайте увагу на дрібниці. Непослідовності часто є лише верхівкою айсберга, наприклад, кнопка, що короткочасно підсвічується іншим кольором, або лічильник, який показує «1 товар», коли в кошику два.
Ставте під сумнів припущення. Якщо застосунок очікує виконання кроків у певному порядку, спробуйте змінити цей порядок, відкрити кілька вкладок або увімкнути throttling.

ТИПОВІ ПОМИЛКИ ПОЧАТКІВЦІВ

Перша помилка: тестувати лише те, що зазначено в тест-кейсі. Тест-кейс — це орієнтир, а не обмеження. Якщо помітили щось підозріле, обов’язково перевірте це.

Друга помилка: зупинятися на першому знайденому багові. Часто за одним багом може бути ще кілька у тому самому модулі.

Третя помилка: ігнорувати нетипові сценарії. Фраза «хто ж так робитиме?» часто призводить до того, що баги потрапляють у продакшн. Хтось обов’язково спробує зробити саме так.

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