Якісні баг-репорти в QA: поради й інструменти

Давайте одразу чесно. Баг-репорт, це не формальність, а інструмент комунікації. І як будь-який інструмент, він може бути гострим і корисним або іржавим і марним. Залежить від того, хто і як його використовує.

Я бачив репорти, від яких розробник відразу розумів проблему і фіксив її за годину. І я бачив репорти, після яких починалось листування на три дні, п'ять уточнень і зрештою фраза: «я не можу відтворити». Різниця між цими двома сценаріями, у якості самого репорту.

Тож поговорімо про те, як писати репорти, які реально допомагають.

Що таке баг-репорт і навіщо він взагалі потрібен

Уявіть, що ви викликали майстра, щоб полагодити кран. Він приходить, а ви кажете: «Щось там капає». Що зробить майстер? Почне питати: де капає, коли почало, як часто, після чого, яке тому передувало. Він витратить час на те, щоб зрозуміти проблему, перш ніж щось робити.

Баг-репорт, це саме той опис проблеми, який дозволяє «майстру» (розробнику) одразу взятися за роботу, не ставлячи зайвих запитань. Хороший репорт економить час усієї команди. Поганий, збільшує час виходу продукту на ринок і псує стосунки між QA і девами.

АНАТОМІЯ ЯКІСНОГО БАГ-РЕПОРТУ

Не існує єдиного стандарту, що обов'язково має бути в репорті. Різні компанії, різні трекери, різні вимоги. Але є базовий набір полів, без яких репорт просто не працює.

1. Заголовок (Summary)

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

Погано: «Не працює кнопка»

Добре: «Кнопка Save не реагує на клік, якщо поле Name порожнє»

Різниця очевидна. Перший заголовок нічого не говорить. Другий одразу дає контекст.

2. Кроки відтворення (Steps to Reproduce)

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

Кожен крок: одна дія. Жодних «зайти і натиснути» в одному рядку.

3. Очікуваний результат (Expected Result)

Що мало би статися? Звідки ви знаєте, що це баг, а не «так і задумано»? Очікуваний результат спирається на вимоги, специфікацію або загальноприйняту логіку поведінки. Не пишіть «має працювати нормально». Пишіть конкретно: яке повідомлення, яка дія, який стан системи.

4. Фактичний результат (Actual Result)

Що відбулось насправді. Тут важливо бути точним: не «все зламалось», а «форма закрилася без збереження даних і без повідомлення про помилку». Чим точніше, тим легше розробнику зрозуміти, де копати.

5. Середовище (Environment)

Браузер і версія, операційна система, тестове середовище (staging, dev, prod), версія продукту або білд. Один і той самий баг може відтворюватися тільки в Chrome, але не в Firefox. Або тільки на Windows. Без цієї інформації розробник може шукати проблему не там.

6. Пріоритет і Severity

Ці два поняття часто плутають, і це окрема тема. Коротко: Severity — це наскільки серйозно баг впливає на систему (технічний параметр). Priority — наскільки терміново його треба виправити (бізнесовий параметр). Баг може мати високу Severity, але низький Priority, і навпаки.

7. Докази: скріншоти, відео, логи

Без доказів репорт, це просто слова. Скріншот з виділеною проблемою коштує більше, ніж абзац тексту. Відео взагалі знімає всі питання про відтворення. Логи консолі або мережі, це золото для розробника. Якщо є можливість прикріпити, прикріплюйте завжди.

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

За роки в QA і викладання я бачив одні й ті самі помилки знову і знову. Ось найпоширеніші:

Репорт-загадка

«Зайшов на сторінку, щось натиснув, потім не змогло». Автор знає, що він мав на увазі. Більше ніхто. Кроки — це не потік свідомості, це чітка послідовність дій.

Емоційний репорт

«КРИТИЧНО!!! ВСЕ ЗЛАМАЛОСЬ!!! PROD НЕ ПРАЦЮЄ!!!» Зрозуміло, що людина переживає. Але репорт — це технічний документ, не крик в нікуди. Емоції заважають читати. Пишіть спокійно, навіть якщо серце б'ється частіше.

Декілька багів в одному репорті

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

Відсутня специфіка середовища

«Перевірив у браузері» — у якому? Яка версія? На якому пристрої? Деякі баги живуть виключно в конкретній версії конкретного браузера на конкретній OS. Без цих даних розробник може витратити годину і нічого не знайти.

Очікуваний результат «з голови»

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

ІНСТРУМЕНТИ: ДЕ І ЯК ФІКСУВАТИ БАГИ

Баг-репорт може жити в різних місцях залежно від процесів команди. Ось основні інструменти, з якими ви зустрінетесь у реальній роботі:

Jira

Найпопулярніший трекер у середніх і великих командах. Гнучкий, інтегрується з усім підряд. Має власні поля для Severity, Priority, компонента, версії. Саме в Jira ви, швидше за все, будете вести більшість своїх репортів. Мінус: може бути перевантаженим налаштуваннями, особливо для новачків.

GitHub Issues / GitLab Issues

Якщо команда живе в Git, баги часто фіксуються прямо там. Простіше, ніж Jira, але менше полів. Добре підходить для невеликих продуктів або опенсорс-проектів.

TestRail, Zephyr, Xray

Це інструменти для управління тестуванням, де баг-репорти пов'язані з тест-кейсами. Добре видно, який тест провалився і який репорт з нього вийшов. Популярні в командах з розвиненим QA-процесом.

Trello, Notion, навіть Excel

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

І НА КІНЕЦЬ

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

І ще одне, що я кажу своїм студентам на кожному курсі: баг-репорт — це ваше обличчя як тестувальника. Поки вас не знають особисто, команда судить про вас за тим, які репорти ви пишете. Хочете виглядати професійно — пишіть так само.

Практикуйтеся. Перечитуйте свої репорти, перш ніж відправляти. Питайте себе: «Чи зможе хтось чужий відтворити це за моїм описом?» Якщо так — репорт готовий.