Як ми тестуємо: приклад баг-репорту та тест-кейсу.

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

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

Навіщо стандартизувати баг-репорти

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

Стандартний формат дає три речі:

• швидкість: розробник одразу бачить, що робити, і не витрачає ранок на допит;
• порівнянність: десять багів у однаковій структурі легко відсортувати за впливом;
• пам'ять: через пів року можна знайти, що вже ламалося, і додати регресійний тест.

Саме тому в нашому ручному тестуванні сайтів кожен баг у звіті має однакову форму і відео.

Анатомія баг-репорту

Ось поля, які ми заповнюємо завжди.

Заголовок

Заголовок відповідає на три питання: де, що, за яких умов. Порівняйте:

• Погано: «Не працює кошик».
• Добре: «Кошик: після видалення товару купон залишається, і знижка рахується від старої суми».

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

Середовище

Без середовища баг може бути нерепродукованим. Фіксуємо:

• URL і версію збірки або дату деплою;
• пристрій і ОС (iPhone 13, iOS 17.5; Windows 11);
• браузер і версію;
• роль користувача (гість, авторизований, адміністратор);
• тестові дані (який товар, який купон, який метод оплати).

Кроки відтворення

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

Очікуваний і фактичний результат

Це два окремі рядки. Очікуваний результат спирається на вимоги або логіку («після видалення товару знижка перераховується»), фактичний описує те, що сталося. Так розробник одразу бачить розрив. Якщо очікувана поведінка суперечить документації, вказуйте джерело.

Серйозність і пріоритет

Це різні поняття, і їх плутають найчастіше.

Баг із друкарською помилкою в логотипі на головній має низьку серйозність, але може мати високий пріоритет. Баг, що ламається лише на Internet Explorer 11, може мати високу серйозність, але нульовий пріоритет, бо трафіку з цього браузера немає.

Наша шкала серйозності:

• S1 (критична): блокує основний сценарій, втрата грошей або даних. Приклад: оплата не проходить.
• S2 (висока): основний сценарій працює, але з помітним спотворенням. Приклад: неправильна сума знижки.
• S3 (середня): є обхідний шлях. Приклад: фільтр скидається при поверненні назад.
• S4 (низька): косметика, дрібниці UI.

Докази

Скриншот із виділеною проблемою, відео запису екрана (для динамічних багів воно майже обов'язкове), логи консолі та мережі, якщо є. Відео економить десятки повідомлень у переписці. Для мобільних багів корисно, щоб на записі було видно індикатори пристрою.

Приклад баг-репорту

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

BUG-017. Кошик: після видалення товару купон залишається, і знижка рахується від старої суми

Серйозність: S2. Пріоритет: P1. Статус: новий.

Середовище: staging, збірка від 2026-10-01, Chrome 129 / Windows 11 і Safari / iPhone 13 (iOS 17.5). Роль: гість.

Передумови: у каталозі є товар A (1 000 грн) і товар B (500 грн). Діє купон SALE10 (знижка 10% на замовлення від 1 200 грн).

Кроки:

1. Додати в кошик товар A і товар B (сума 1 500 грн).
2. Застосувати купон SALE10. Підсумок: 1 350 грн.
3. Видалити з кошика товар A.
4. Подивитися підсумок.

Очікуваний результат: залишився товар B на 500 грн. Купон не діє (мінімум 1 200 грн), підсумок 500 грн, користувач бачить повідомлення, що купон скасовано.

Фактичний результат: підсумок 450 грн, купон залишається застосованим. При оформленні замовлення сума 450 грн.

Відтворюваність: 3 з 3 спроб. Докази: відео bug-017.mp4, скриншот кошика.

Примітка: схожий баг можливий при зміні кількості товару через «мінус».

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

Типові помилки в баг-репортах

• Кілька багів в одному тікеті. Розробник виправить один, а тікет закриє. Один баг, один тікет.
• Оцінка замість факту. «Жахливо працює пошук». Факт: «пошук за словом "куртка" повертає 0 результатів, хоча товарів 14».
• Відсутність очікуваного результату. Без нього тікет стає питанням смаку.
• Баг у чужому середовищі. Перевірте, що проблема не в розширенні браузера й не в кеші, перш ніж писати репорт.
• Закритий тікет без перевірки. «Виправлено» має означати «QA повторив кроки й підтвердив».

Анатомія тест-кейсу

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

Поля тест-кейсу:

Приклад тест-кейсу

CHK-004. Оформлення замовлення гостем з оплатою карткою (позитивний сценарій)

Пріоритет: високий (входить у smoke-набір).

Передумови: товар у наявності, платіжний провайдер у sandbox-режимі, користувач не авторизований.

Кроки:

1. Відкрити картку товару, додати в кошик.
2. Перейти в кошик, натиснути «Оформити замовлення».
3. Заповнити контактні дані (ім'я, телефон, e-mail).
4. Обрати доставку Новою Поштою: місто, відділення.
5. Обрати оплату карткою, натиснути «Підтвердити».
6. Ввести тестову картку на сторінці платіжної системи.

Очікуваний результат: після кроку 6 відкривається сторінка «Дякуємо», номер замовлення збігається з листом підтвердження, статус замовлення в адмінці «оплачено», залишок товару зменшився на 1.

Саме такий кейс входить у наш smoke-набір: короткий список із десятка сценаріїв, які проходять після кожного деплою за 15–20 хвилин. Якщо хоч один падає, реліз зупиняється.

Позитивні, негативні та граничні кейси

Для кожної функції ми складаємо мінімум три групи кейсів. Візьмемо поле «Телефон» у чекауті:

• Позитивний: +380501234567 приймається.
• Негативний: літери, порожнє поле, номер без коду країни, SQL-подібний рядок (' OR 1=1 --) не ламають форму і не потрапляють у базу як код.
• Граничний: 9 цифр, 10, 13, 14; пробіли на початку; вставка номера із дужками й дефісами.

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

Від тест-кейсу до результату: як виглядає наш процес

1. Аналіз вимог. Читаємо ТЗ, макети й сам сайт, шукаємо неоднозначності. Питання до замовника на цьому етапі коштують дешевше за баги.
2. Тест-план. Фіксуємо, що тестуємо, що ні, на яких пристроях, яким браузером і за який час.
3. Тест-кейси. Пишемо їх або беремо з нашого чек-листа інтернет-магазину (150+ пунктів), адаптуємо під проєкт.
4. Виконання. Проходимо сценарії, фіксуємо результат. Паралельно проводимо дослідницьке тестування: вільні сценарії поза списком, де часто й знаходяться найцікавіші баги.
5. Баг-репорти. Кожен баг одразу оформлюємо за шаблоном із відео.
6. Звіт. Підсумок: що перевірено, що знайдено, розподіл за серйозністю, рекомендація «можна релізити чи ні».
7. Ре-тест. Після виправлень перевіряємо кожен виправлений баг і прогоняємо регрес навколо нього.

Окремо про регрес. Виправлення одного бага часто ламає сусідній функціонал, тому ми не обмежуємося перевіркою самого фіксу. Якщо сценарій ключовий, його варто винести в автотест: про те, коли це виправдано, ми писали в статті про ручне та автоматизоване тестування.

Потрібен такий звіт для вашого сайту? Ми тестуємо вручну, фіксуємо кожен баг за шаблоном із відео й пріоритизуємо за впливом на гроші. Дізнатися про ручне тестування.

Як ми пріоритизуємо знайдене

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

1. Спочатку все, що блокує покупку: кошик, чекаут, оплата, доставка.
2. Далі баги, що псують дані: неправильні суми, дублі замовлень, втрачені листи.
3. Потім проблеми, що відштовхують клієнта: повільні сторінки, зламана мобільна версія, незрозумілі помилки форм.
4. В останню чергу косметика й дрібні неточності.

Так замовник одразу бачить, з чого почати, і може виправити 20% багів, які дають 80% проблем.

Інструменти: що нам потрібно, а що ні

Не потрібна дорога система, щоб робити тестування якісно. Для малих команд достатньо:

• Баг-трекер: Jira, Linear, GitHub Issues або навіть Trello. Головне, щоб шаблон тікета був однаковим.
• Тест-кейси: таблиця (Google Sheets) або TestRail-подібний інструмент. Для 30–60 кейсів таблиці вистачає.
• Запис екрана: вбудований запис у macOS та iOS, Android; для десктопу OBS або Loom.
• Інспектор: DevTools (вкладки Console і Network) для логів і запитів.
• Емулятори й реальні пристрої: емуляція в DevTools корисна, але мобільні баги з Safari та клавіатурою краще перевіряти на реальних iPhone й Android.

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

Як оцінити якість звіту від QA

Якщо ви замовляєте тестування і хочете зрозуміти, чи вам віддали якісну роботу, перевірте:

• чи кожен баг має кроки, очікуваний і фактичний результат та докази;
• чи є розподіл за серйозністю, а не просто довгий список;
• чи вказані середовища (пристрої, браузери, версія збірки);
• чи є список того, що не перевірялося, і чому;
• чи є висновок: готовий продукт до релізу чи ні.

Звіт без останнього пункту неповний. Тестування існує, щоб допомогти ухвалити рішення, а не щоб створити кількість тікетів. Докладно про те, що саме перевіряємо в магазині, дивіться у чек-листі з 60 пунктів, а про одну з найболючіших груп багів у статті про втрату замовлень на checkout.

Підсумок

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

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

Хочете почати з експрес-чека? Надішліть адресу сайту в брифі, і ми за 48 годин повернемо 10–15 ключових проблем з відео. Надіслати бриф.