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

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

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

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

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

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

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

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

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

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

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

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

Перший крок має містити вказівку перейти за URL середовища замовника, наданим у розділі Access, якщо ви тестуєте вебсайт, або вказівку відкрити застосунок (із зазначенням його назви), якщо ви тестуєте мобільний застосунок. Приклад:

Для вебсайтів:

Для мобільних застосунків:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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