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

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

Після вибору Функції (Feature) уся форма для звіту про баг стане доступною для заповнення. Наприклад, форма для функціональних багів виглядає так:

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

Для функціональних багів доступне додаткове поле Рівень критичності (Severity): Low (низький), High (високий) та/або Critical (критичний). Рівень критичності вказує на терміновість вашого звіту і залежить від кількох факторів. Щоб дізнатися більше про різні рівні критичності, будь ласка, ознайомтеся зі статтею Функціональні баги.

Поле Рівень критичності (Severity) не відображатиметься для інших типів багів.

Заголовок звіту про баг має коротко підсумовувати проблему, щоб читач міг отримати загальне уявлення про баг лише прочитавши заголовок. Йому не повинно бути потрібно читати весь звіт, щоб зрозуміти суть проблеми. Ваш заголовок повинен бути точним і водночас не надто довгим. Він має містити інформацію: що за баг, де стався баг і коли він виникає. Тож, складаючи заголовок, завжди пам’ятайте: Що? Де? Коли?

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

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

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

Неправильно: Помилка відображається на сторінці кошика.
​Правильно: Кнопка "Оформити замовлення" на сторінці Кошика перенаправляє користувачів на сторінку з помилкою "Error 500"

Неправильно: Користувач не може додати товар до кошика
​Правильно: На сторінці "Футболка Бетмена" користувачі отримують повідомлення "Unexpected Error" при спробі додати товар до кошика

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

URL-адреса має бути дійсною.

Баги мають бути відтворюваними, тому потрібен детальний покроковий опис, як їх можна відтворити. Кожен крок повинен описувати окрему дію.

Перший крок має містити вказівку на доступ до URL цільової сторінки, наданої клієнтом у розділі Access, якщо ви тестуєте сайт, або вказівку відкрити додаток (з його назвою), якщо тестуєте мобільний додаток. Усі наступні кроки мають описувати ваші дії від початкового кроку до моменту виникнення бага — які кнопки ви натискаєте, які посилання переходите, що вводите. Останній крок має описувати дію, яка спричиняє баг. Пам’ятайте, що “спостереження” — це не дія користувача.

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

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

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

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

Те, що фактично відбувається після виконання покрокового керівництва, має бути описано якомога детальніше. Намагайтеся бути дуже точними і не використовувати занадто загальні формулювання, наприклад, замість того, щоб сказати, що продукти в основному залишаються у тому ж порядку після застосування методу сортування X, наведіть конкретні приклади продуктів, які розташовані неправильно. Додайте до цього поля будь-яку інформацію, яка стосується бага, наприклад, приклади, додаткові умови, виключення чи результати інших важливих дій, якщо це необхідно. Головне — структуровано подати інформацію, щоб допомогти читачеві зрозуміти ваш хід думок.

Також фактичний результат не повинен бути однаковим із заголовком звіту. Заголовок — це короткий виклад проблеми, тоді як фактичний результат має бути детальним описом з додатковою інформацією, такою як умови сценарію, приклади та результати, отримані під час виконання кроків для відтворення бага.

Неправильно: Помилка відображається на сторінці кошика після натискання кнопки Оформити замовлення.
​Правильно: Повідомлення «Error 500 – Internal Server error – Sorry something went wrong» відображається після спроби перейти на сторінку оформлення замовлення..
​
​Неправильно: Користувач не може додати товар у кошик, відображається помилка.
​Правильно: У верхньому правому куті сторінки товару (PDP) з’являється повідомлення про помилку «Unexpected Error», і товар не додається до кошика.

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

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

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

​Неправильно: Товар має бути успішно доданий до кошика.
​Правильно: Товар «Футболка Бетмена» має бути успішно доданий до кошика. Користувач не повинен бачити помилки на кшталт «Error 505» і має мати можливість оформити замовлення на будь-який товар у кошику.

Щоб дізнатися, який тип вкладення потрібно прикріпити до вашої помилки та які правила застосовуються, перегляньте таку статтю: Вимоги до вкладень звіту про помилку.

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

Ви можете використовувати лише ті пристрої для тестування, які вказані у цьому розділі. Крім того, ви повинні обирати лише один пристрій або браузер при створенні звіту про баг і додавати вкладення тільки для нього. Якщо ви можете відтворити баг на інших пристроях або в інших браузерах — згадайте про це у полі Actual result.

Вибір правильного середовища, в якому виникає баг, є обов’язковим. Перед тим як надіслати звіт, переконайтесь, що ви вибрали правильне середовище. Якщо ви випадково обрали неправильне, його можна виправити після надсилання звіту — до того, як його перевірить тимлід. Якщо у звіті буде вказано неправильне середовище, тимлід відхилить його під час перевірки.

Хочете тестувати на пристрої, якого немає у списку доступних у вашому профілі? Просто надішліть нам запит через чат підтримки, і ми додамо цей пристрій до вашого списку, якщо він є релевантним для наших клієнтів.

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

Якщо баг виникає лише за певного вводу, використовуйте слова та фрази, які міг би використати реальний користувач, і уникайте випадкового набору символів. Наприклад, створюючи акаунт на стороні клієнта, не слід використовувати імена на кшталт “asdsdfkg_lajsdh”, оскільки це виглядає непрофесійно та погіршує якість звіту.

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