Уявіть: користувач пише в підтримку: «У мене не працювала кнопка оплати». Ви заходите, тестуєте, все працює ідеально. Знову тестуєте. Ідеально. Питаєте у розробника: «Ти щось змінював?» Ні. Баг зник сам. Або не зникав? Або й не існував? Ласкаво просимо до світу багів-привидів. Тих, що з'являються без запрошення і зникають без пояснень.
ХТО ЦІ ПРИВИДИ?
Перш ніж полювати, треба знати, на кого полюєш. Баги-привиди не є офіційною класифікацією з підручників з інформатики. Це інженерний сленг, який народився у розмовах між розробниками і зібраний у легендарному словнику хакерського сленгу «The Jargon File». Три головні персонажі:
Floating bug (Плаваючий): баг, що з'являється і зникає без видимої причини. Сьогодні є, завтра немає, післязавтра знову є. Зазвичай залежить від стану пам'яті, навантаження на сервер або порядку запитів.
З реального життя: кран на кухні іноді капає. Сантехнік приходить, перевіряє, краплі немає. Йде. Крапля повертається. Причина може бути в тиску води в мережі, температурі або фазі місяця. Здається, так і з деякими багами.
Heisenbug (Хайзенбаг): названий на честь фізика Гейзенберга та його принципу невизначеності. Суть: баг зникає, щойно ти починаєш його досліджувати. Підключив дебагер, поставив точки зупинки, написав логи, і... все працює. Причина часто в тому, що логи і дебагер змінюють швидкість виконання коду, а баг залежав саме від таймінгу.
З реального життя: дитина поводиться погано, поки батьків немає вдома. Вчитель не вірить, каже «у мене на уроці все чудово». Обидва мають рацію, просто умови різні.
Sporadic bug (Спорадичний): баг, що виникає час від часу без будь-якої закономірності. На відміну від floating, тут навіть немає ритму появи. Може тричі за один день, потім мовчання два тижні.
З реального життя: ліфт у старому будинку іноді не реагує на кнопку першого поверху. Не завжди, не за погодою, не в певний час. Просто іноді. Мешканці вже знають: натисни ще раз.
ЗВІДКИ ВОНИ БЕРУТЬСЯ?
Розуміти природу цих багів важливіше, ніж знати їх назви.
Ось типові причини:
- Race condition: два процеси одночасно намагаються змінити одні й ті самі дані. Хто встигне першим, невідомо.
- Витоки пам'яті: баг проявляється лише після кількох годин роботи, коли пам'ять вже на межі.
- Залежність від зовнішніх сервісів: API третьої сторони відповів повільніше, і система не справилась.
- Дані у специфічному стані: баг спрацьовує лише для певного поєднання полів у базі, яке трапляється рідко.
- Різниця між середовищами: на prod є кешування, на test немає. Баг живе лише на prod. Усе це означає одне: ці баги не випадкові. У них є причина. Просто вона прихована глибше, ніж зазвичай.
ТО ЛОВИТИ ЧИ ВІДПУСТИТИ?
І ось головне питання. Інтуїція підказує: звичайно ловити! Але досвідчений тестувальник знає, що це не завжди правильна відповідь.
Коли полювати
- Баг у критичному місці: оплата, авторизація, збереження даних.
- Є хоч якийсь патерн: з'являється вночі, під навантаженням, на конкретному браузері.
- Користувачі скаржаться регулярно: навіть якщо ти не можеш відтворити, вони можуть.
- Є логи або метрики, де баг залишає сліди.
Коли відпустити (тимчасово)
- Баг не відтворювався вже тиждень і немає жодного сліду в логах.
- Критичність низька, і команда зайнята важливішими задачами.
- Відтворення потребує годин роботи без гарантії результату.
Але «відпустити» не означає «забути». Це означає: зафіксувати, налаштувати алертинг (система автоматичних повідомлень, яка сама пише тобі, коли щось пішло не так) і моніторинг, і чекати, поки він з'явиться знову, цього разу з доказами.
| Ситуація | Полювати | Відпустити |
|---|---|---|
| Баг у критичному флоу (оплата, авторизація) | Так, завжди | Ні |
| Баг трапляється 1 раз за 2 тижні | Якщо є час і логи | Можливо |
| Не відтворюється вже тиждень | Ні | Так, з моніторингом |
| Prod падає щоночі о 3:00 | Так, терміново | Ні |
Рекомендуємо курси по темі
ЯК ЛОВИТИ: ПРАКТИЧНІ ПОРАДИ
- Фіксуй середовище: OS, мережа, чи був VPN, скільки часу пройшло після останнього логіну.
- Якщо баг зник, не закривай тікет, а описуй умови зникнення так само ретельно.
- Записуй кроки з максимальною деталізацією: браузер, версія, час, які вкладки були відкриті паралельно.
- Зверни увагу на час: чи не збігається поява з резервним копіюванням, оновленням кешу або нічним cron-завданням?
- Спілкуйся з користувачами: вони часто знають більше, ніж здається. «Це завжди трапляється, коли я відкриваю дві вкладки» — це вже зачіпка.
- Спробуй відтворити в інших умовах: інший браузер, інший акаунт, інший пристрій.
- Повідом розробнику не просто «не відтворюється», а «не відтворюється в таких умовах, але користувач описав ось це».
Баги-привиди — не вигадки нервових QA-інженерів. Це реальна категорія проблем, з якою стикається кожна команда. І найважливіший навик тут не технічний: це вміння приймати рішення в умовах невизначеності. Полювати на кожен примарний баг до переможного кінця, не ефективно. Ігнорувати їх повністю, небезпечно. Золота середина: фіксувати, спостерігати, розставляти пастки і чекати, коли привид сам себе видасть.
Хороший тестувальник не просто знаходить баги. Він знає, які з них варто ловити прямо зараз, а які самі прийдуть, коли буде достатньо доказів.
