Manual QA

Баги

репорти, severity, життєвий цикл

Що має бути в хорошому баг-репорті?

Заголовок: що, де, за якої умови. Не «не працює переказ», а «Переказ падає з 500, якщо сума має 3 знаки після коми».
Середовище: білд, браузер, ОС, пристрій, користувач.
Передумови і кроки відтворення — мінімальні.
Фактичний і очікуваний результат.
Докази: скріншот, відео, лог, запит і відповідь із DevTools.
Severity, priority, частота відтворення.

Заголовок: [Payments] Переказ повертає 500, якщо сума має 3 знаки після коми
Середовище: staging, build 2.14.3, Chrome 129, Windows 11
Передумови: користувач qa_user_03, баланс 5 000.00 UAH
Кроки:
  1. Відкрити «Переказ на картку»
  2. Ввести суму 100.555
  3. Натиснути «Продовжити»
Фактично: помилка «Щось пішло не так»; POST /api/transfers → 500
Очікувано: валідація поля «Не більше 2 знаків після коми», запит не відправляється
Відтворюється: 5/5
Додатки: video.mp4, HAR-файл, request/response

На співбесіді: Хороший репорт має заголовок, з якого зрозуміло, що зламано і за якої умови, середовище, мінімальні кроки, фактичний і очікуваний результат і докази — скріншот, відео, запит і відповідь з DevTools. Мета — щоб розробник відтворив баг без жодного питання до мене.

Чим severity відрізняється від priority?

Severity — наскільки сильно дефект впливає на систему. Визначає QA.

Priority — наскільки терміново треба виправити. Визначає бізнес або PM.

	Високий priority	Низький priority
Висока severity	Не проходять платежі	Падає звіт, яким користуються раз на рік
Низька severity	Помилка в назві банку на головній	Зсунутий піксель у футері

На співбесіді: Severity — це технічний вплив дефекту на систему, і її визначає QA. Priority — наскільки терміново виправляти, і це рішення бізнесу. Вони не завжди збігаються: друкарська помилка в назві банку на головній — низька severity, але високий priority, бо б'є по репутації.

Який життєвий цикл бага?

Типово: New → Assigned → In Progress → Fixed → Ready for QA → Verified → Closed.

Відгалуження: Reopened (ретест не пройшов), Rejected / Not a bug, Duplicate, Cannot reproduce, Deferred / Won't fix. Конкретні статуси залежать від workflow в Jira на проєкті.

На співбесіді: Баг створюється, призначається розробнику, виправляється, повертається на QA, я роблю ретест і закриваю. Якщо ретест не пройшов — переоткриваю. Ще бувають статуси на кшталт дубля, не відтворюється, не баг чи відкладено. Точний workflow залежить від налаштувань Jira на проєкті.

Що робити, якщо баг не відтворюється?

Повторити в точно тих самих умовах: середовище, білд, користувач, дані, браузер.
Зібрати більше даних: логи, консоль, мережа, час інциденту, ID транзакції.
Шукати умови: гонка (швидкі дії), кеш, часовий пояс, конкретні дані, навантаження.
Попросити розробника перевірити серверні логи за часом.
Якщо так і не відтворюється — задокументувати все знайдене, частоту і відкласти з моніторингом, а не просто закрити.

На співбесіді: Спочатку відтворюю в точно тих самих умовах — середовище, білд, користувач, дані. Збираю логи, мережу і час інциденту, шукаю особливі умови на кшталт гонки чи кешу і прошу розробника глянути серверні логи. Якщо не відтворюється, я документую все знайдене і частоту, а не просто закриваю.

Розробник каже «це не баг». Як дієш?

Спершу перевірити себе: що каже вимога, макет, домовленість? Можливо, я неправильно зрозумів очікувану поведінку.

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

Головне — сперечатися про поведінку продукту, а не про те, хто правий.

На співбесіді: Спочатку перевіряю себе за вимогою і макетом. Якщо вимога чітка — показую її і докази. Якщо неоднозначна, питання йде до PM, бо очікувану поведінку визначає продукт, а не ми з розробником. Рішення фіксую в тікеті, щоб не повертатися до цього вдруге.

Баг-репорт і кроки відтворення

Структура: заголовок, середовище, передумови, кроки відтворення, фактичний результат, очікуваний результат, severity, priority та вкладення. Заголовок відповідає на питання «що, де, за яких умов», наприклад «Кошик: загальна сума не оновлюється після видалення товару». Середовище включає браузер, ОС, версію збірки, стенд і тестовий акаунт.

Кроки мають бути нумерованими, мінімальними й достатніми, щоб будь-хто відтворив баг з першого разу. Перед написанням варто перевідтворити баг і відкинути зайві кроки. Обов'язково вказую конкретні тестові дані та частоту відтворення, якщо баг плаваючий.

Вкладення — скріншот, відео, логи консолі, HAR-файл або відповідь API. Один баг — один репорт, і перед створенням перевіряю, чи немає дубліката.

Severity vs priority

Severity — наскільки дефект впливає на систему технічно; її визначає QA. Priority — наскільки терміново його треба виправити з точки зору бізнесу; зазвичай визначає PO або менеджер. Ці параметри незалежні один від одного.

Висока severity, низький priority: застосунок падає, якщо ввести 1000 символів у рідко використовуване поле налаштувань старої версії звіту. Низька severity, високий priority: помилка в назві компанії або логотипі на головній сторінці перед релізом. Висока severity і високий priority: користувачі не можуть оплатити замовлення.

Типові рівні severity: blocker, critical, major, minor, trivial. Priority зазвичай має рівні high, medium, low або P1–P4.