> For the complete documentation index, see [llms.txt](https://swit-school.gitbook.io/qa-book/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://swit-school.gitbook.io/qa-book/testuvannya-igor/bug-report/struktura-bag-reporta.md). # Структура баг-репорта ## Життєвий цикл bug report Ми розглянемо найпростіший життєвий цикл, який складається з наступних кроків: * **To do.** Знайдений баг занесено до баг-трекінгової системи. * **In progress.** Над проблемою розпочато роботу відповідальними особами. * **Ready to QA.** Баг виправлено та відправлено на перевірку QA * **In QA.** Баг, який було пофікшено взято на перевірку QA * **Done.** Баг закрито. ## Структура баг-репорта **Зразок баг-репорта** - Перерахуємо і детальніше розглянемо основні атрибути баг-репорта. **Project** - обрати правильний проект, якщо їх у тестувальника декілька. Обов'язково перевірити актуальність проекту в якому знайдено помилку та буде заведений баг-репорт ![](https://lh3.googleusercontent.com/7kTa2AgwLiIVnfWinz3Og6LD8M_a-3-wzXvknMeUjbCzk6J9K1VqmIo4Rb8Zf7lYMq2Z8NnKVHczfHFu7cOl17OInmjLxVOGb5AefwmfEL0R1BG5voMoikB3NcoRwBCuiaKBVJgGWNSjDEBLHf0R7qc) **Tasks** - перевірити чи правильно виставлено тип задачі. Має бути Bug. ![](https://lh4.googleusercontent.com/kQ4rasr0LT5ZFxlCaFruvKuJGXFJZ-SznYKf9iMNzdXgBlQ3yoe0z7H2eNfZjnJvbWuGPj-Sh6_zCtcID5hTt2fgr_gGntIpyD0r0MzhCrm4G8CGzVdiCK1ZOuY4IXYPZIPFki1ZrbDhD9RO7uA7tcU) **Summary** - У цьому полі необхідно коротко викласти суть бага. Для того, щоб в повній мірі описати баг, необхідно послідовно відповісти на три питання: ЩО не так працює? в якому місці продукту, тобто ДЕ? і КОЛИ дана проблема з’являється? Наприклад: Не працює кнопка Play на мейн сцені після натискання ЩО? - не працює кнопка Play ДЕ? - на мейн сцені КОЛИ? - коли натискаємо ![](https://lh6.googleusercontent.com/MEJwTXi2YeKY5Mx795h_ttsSjG-vl9J2g1wEYz_pbld74bkERSjE1m1U5gFnxtZJPCVpbhpUbIKLItX_1w2HX8ShxxTljyLP5_KtOwFg7OlbyhB0Jn2mtTlvg8e9JZXYAEai4HECGqlEO-ZjlwmTJY0) **Device** - вказуємо назву девайса на якому було знайдено помилку **Android/IOS version** - вказуємо версію операційної системи девайса, на якому було виявлено помилку **Screen resolution** - вказуємо розширення (розмір) екрану девайса на якому було знайдено помилку **Build:** вказуємо актуальну версію збірки гри в якій було виявлено баг. ![](https://lh5.googleusercontent.com/6i5wLTVB-XZMMuJZqQxq1kSSuvGbVOsEBYj1oMe3jZcPqc6Q3RkoPxkBjRHoOqxgHjKLYYXn8vemnYNuSYXPDtUqncpjuCX6S8Ev8NEr9DQY58nrc40p5akBDVL4Rbrod3113zxyj3t61s-jm4cj2Yw) **Description (Детальний опис)** - поле для детального опису знайденої проблеми. Простіше, в цьому полі розписуємо проблему більш широко, якщо саммері не відображає проблему в достатній мірі. Наприклад: Summary Гра крашиться (ЩО?) в Маркеті (ДЕ?) коли робити покупку (КОЛИ?) Description: Гра дає збій (крашиться), коли робити покупку за реальну валюту в Маркеті гри. ![](https://lh6.googleusercontent.com/hOQbJaG98jS1pD9o3KnqjGnOa2P-XLyeNzH4T09JwzJ8giBGEIeuyAHX3fx2xFR3h2HEm6WNRo55jLxYQYbq-Fs0KJIq3ibmZoAdY2M1t_etWIIF65_zibchxRDQUDqitossg_pKlZIkTDNXBQRSeZs) Для заповнення поля опису в джирі потрібно підготувати заздалегідь шаблон. Приклад шаблону: ![](https://lh4.googleusercontent.com/P3i3ItW5kOSU2COcX9CELAOfykMv9eMlI-n7sgopxmwxejQEI0IoNqarRiB5rzt0MjiTCr_8pBqHOsjcBmDE9khxLCZJYc_7YbMP1To4iurt44QcXopmNyusAmvB-VaTZCyOmKDp8PiVTkCSQviud94) **Precondition (передумови)** - список усіх необхідних підготовчих дій (налаштування програми, середовища тестування) для виконання відтворення баги. Наприклад : 1. Мати стабільний інтернет 2. Мати не менше 500 монет 3. Гра з реальним гравцем (не бот) **Steps to reproduce (кроки до відтворення)** - необхідно точно описати всі кроки, щоб можна було без проблем відтворити помилку. Наприклад: Баг: Не матчаться тайли на ігровому полі під час гри. Steps to reproduce: 1. Запустити гру 2. Вийти на основну сцену. 3. Тапнути на ігровий стіл зі ставкою 50 монет. 4. Підтвердити ставку. 5. Зробити матч на ігровому полі на своєму ході. **Actual result** - вказується що працює не так, в якому місці гри і за яких умов (тобто, описуючи фактичний результат необхідно знову - таки відповісти на три питання Що? Де? Коли?). По суті, як правило, фактичний результат повинен бути аналогічний Summary. Наприклад: Не матчаться тайли на ігровому полі під час гри. **Expected result** - вказується, як саме має працювати функціонал на думку тестувальника Наприклад: Матчаться тайли на ігровому полі під час гри за умови, коли з'єднання відбувається три в ряд. **Priority (Пріоритет дефекта)** - це атрибут, що вказує на чергу виконання задачі або усунення дефекту. Можна сказати, що це інструмент менеджера по плануванню роботи. Чим вище пріоритет, тим швидше необхідно усунути дефект. ![](https://lh5.googleusercontent.com/aVl49Ji4m9UzaGDGLq1kVxQyabC5tnl7uRzomvIgrGLcvSVrviRQS3Y1Dx4rS-SnnBT25WHKd0ZvXfc4NU8haArj8X8BtjoO3EhbQKILQRbz-mAjqYQbMf5lqbbQF6DFE4M_dEkQti2Q64fobmPdjPI) **Attachments (Вкладення)** - До баг-репортів потрібно прикріплювати файли, наприклад, скріншот, відео або лог-файл. Це робиться тому, що інформація краще засвоюється візуально, ніж текстово. Якщо додавати скріншот, де візуально показати стрілкою, що «ось тут баг», то, відкривши цей скріншот іноді можна і не читати кроки і description. Бувають такі баги, коли скріншот не підтверджує наявність дефекту. В такому випадку, необхідно обов'язково прикріпити і скріншот, і відео з помилкою. Це потрібно для того, щоб візуально зорієнтувати в якому місці шукати баг і не переглядати відео кілька разів. ![](https://lh5.googleusercontent.com/1aK6v-3oLDCkIGw9PmdLUEv_oUhWuXYMYgg9044ETYk3Bs2XX62aGe9dHWnKFGHemMBjNI-Uf85DkyI1Nah8xKhVal_rYdzMl-uIUlhxKwSfi6Zm8k6CQWdqYc7ZLnLkhjgbjTsfH3KztGOsKQjmJkA) **Assignee (Призначення)** – це атрибут у якому вказується кому присвоюється баг-репорт для подальшої перевірки. ![](https://lh4.googleusercontent.com/LcmB0SAyfIP-f3YXkbYIyKt1a7WCxvoV6HasX9vMOOfbsfysSaO2AKG-XJypfULkcEgAI17BnHoxiVtaFzN0nTjVHfod9vg3puTZj-pNLY1gJf6HamdK06bdkLv4eiU370DutDawIg5w-NJfDS4ZNf0)