3️⃣Структура баг-репорта
Життєвий цикл bug report
Ми розглянемо найпростіший життєвий цикл, який складається з наступних кроків:
To do. Знайдений баг занесено до баг-трекінгової системи.
In progress. Над проблемою розпочато роботу відповідальними особами.
Ready to QA. Баг виправлено та відправлено на перевірку QA
In QA. Баг, який було пофікшено взято на перевірку QA
Done. Баг закрито.
Структура баг-репорта
Зразок баг-репорта - https://doitschoolit.atlassian.net/browse/GQAB-157
Перерахуємо і детальніше розглянемо основні атрибути баг-репорта.
Project - обрати правильний проект, якщо їх у тестувальника декілька. Обов'язково перевірити актуальність проекту в якому знайдено помилку та буде заведений баг-репорт
Tasks - перевірити чи правильно виставлено тип задачі. Має бути Bug.
Summary - У цьому полі необхідно коротко викласти суть бага. Для того, щоб в повній мірі описати баг, необхідно послідовно відповісти на три питання: ЩО не так працює? в якому місці продукту, тобто ДЕ? і КОЛИ дана проблема з’являється?
Наприклад: Не працює кнопка Play на мейн сцені після натискання
ЩО? - не працює кнопка Play
ДЕ? - на мейн сцені
КОЛИ? - коли натискаємо
Device - вказуємо назву девайса на якому було знайдено помилку
Android/IOS version - вказуємо версію операційної системи девайса, на якому було виявлено помилку
Screen resolution - вказуємо розширення (розмір) екрану девайса на якому було знайдено помилку
Build: вказуємо актуальну версію збірки гри в якій було виявлено баг.
Description (Детальний опис) - поле для детального опису знайденої проблеми. Простіше, в цьому полі розписуємо проблему більш широко, якщо саммері не відображає проблему в достатній мірі.
Наприклад:
Summary
Гра крашиться (ЩО?) в Маркеті (ДЕ?) коли робити покупку (КОЛИ?)
Description:
Гра дає збій (крашиться), коли робити покупку за реальну валюту в Маркеті гри.
Для заповнення поля опису в джирі потрібно підготувати заздалегідь шаблон.
Приклад шаблону:
Precondition (передумови) - список усіх необхідних підготовчих дій (налаштування програми, середовища тестування) для виконання відтворення баги.
Наприклад :
Мати стабільний інтернет
Мати не менше 500 монет
Гра з реальним гравцем (не бот)
Steps to reproduce (кроки до відтворення) - необхідно точно описати всі кроки, щоб можна було без проблем відтворити помилку.
Наприклад:
Баг: Не матчаться тайли на ігровому полі під час гри.
Steps to reproduce:
Запустити гру
Вийти на основну сцену.
Тапнути на ігровий стіл зі ставкою 50 монет.
Підтвердити ставку.
Зробити матч на ігровому полі на своєму ході.
Actual result - вказується що працює не так, в якому місці гри і за яких умов (тобто, описуючи фактичний результат необхідно знову - таки відповісти на три питання Що? Де? Коли?). По суті, як правило, фактичний результат повинен бути аналогічний Summary.
Наприклад: Не матчаться тайли на ігровому полі під час гри.
Expected result - вказується, як саме має працювати функціонал на думку тестувальника
Наприклад: Матчаться тайли на ігровому полі під час гри за умови, коли з'єднання відбувається три в ряд.
Priority (Пріоритет дефекта) - це атрибут, що вказує на чергу виконання задачі або усунення дефекту. Можна сказати, що це інструмент менеджера по плануванню роботи. Чим вище пріоритет, тим швидше необхідно усунути дефект.
Attachments (Вкладення) - До баг-репортів потрібно прикріплювати файли, наприклад, скріншот, відео або лог-файл. Це робиться тому, що інформація краще засвоюється візуально, ніж текстово. Якщо додавати скріншот, де візуально показати стрілкою, що «ось тут баг», то, відкривши цей скріншот іноді можна і не читати кроки і description.
Бувають такі баги, коли скріншот не підтверджує наявність дефекту. В такому випадку, необхідно обов'язково прикріпити і скріншот, і відео з помилкою. Це потрібно для того, щоб візуально зорієнтувати в якому місці шукати баг і не переглядати відео кілька разів.
Assignee (Призначення) – це атрибут у якому вказується кому присвоюється баг-репорт для подальшої перевірки.
Last updated