Як правильно оформити баг-репорт

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

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

Критичність та пріоритет бага

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

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

S1 - Блокуючий (Blocker). Баг повністю блокує виконання програми, і немає способу його обійти. Для розуміння, можна навести приклад із реального життя - всі виходи з дому закриті, і ви ніяк не можете залишити приміщення.
S2 - Критичний (Critical). Дефект блокує частину функціоналу, причому існує спосіб його обійти. Розглянемо приклад за аналогією з попереднім: вхідні двері будинку зачинені, проте ви можете залишити приміщення через вікно. Допустимо, але на практиці нераціонально і неприйнятно для нового програмного забезпечення.
S3 - Значний (Major). Блокує роботу одного з основних логічних ланцюжків програмного забезпечення. Найчастіше такий баг пов'язаний не з тим, що функція не працює, а з тим, що вона працює не так, як потрібно.

S4 – незначний (Minor). Баг не впливає на функціонування основної логіки програмного забезпечення. З ним усе працює коректно, без значної втрати якості. Як приклад можна навести вхідні двері з написом «на себе», які насправді відкриваються в інший бік.
S5 - Тривіальний (Trivial). Такий дефект ніяк не впливає на роботу програми і найчастіше залишається непомітним для кінцевого користувача. Це можуть бути невеликі граматичні помилки в тексті, незначне перетинання елементів меню та інше.

Крім критичності, у кожного бага є ще один атрибут — пріоритет, який говорить про те, в якому порядку мають виправлятися помилки. Найчастіше він встановлюється Project-менеджером чи керівником проекту.

Виділяють три рівні пріоритетності:

P1 - Високий (High). Баг вимагає негайного виправлення, оскільки є вкрай важливим для релізу програмного забезпечення або глобальний вплив на функціонування всієї системи.
P2 - Середній (Medium). Помилка важлива, але не потребує негайного виправлення.
P3 - Низький (Low). Незначний баг, який виправляється в останню чергу, після налагодження пріоритетніших дефектів.

Правильне оформлення баг-репорту

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

Заголовок (Summary) - невеликий і ємний опис бага, в якому відображається причина і тип помилки, що виникла.
Проект (Project) – повна назва проекту.
Компонент програми (Component) – частина або функція продукту, де було виявлено помилку.
Номер версії (Version) – версія продукту, в якій знайдено баг.
Критичність (Severity) - ступінь критичності бага за 5-рівневою системою, описаною вище: від S1 до S5.
Пріоритет - рівень пріоритетності вирішення виявленої проблеми: P1, P2 або P3.
Статус (Status) – статус встановлюється відповідно до прийнятого життєвого циклу бага, наприклад: новий, відкритий або закритий.
Автор (Author) - ім'я співробітника, який склав баг-репорт.
Призначений на (Assigned To) - ім'я співробітника, який був призначений відповідальним за налагодження бага.
Опис (Description) - найбільш об'ємна частина баг-репорта, в якій детально описана інформація про оточення, де було знайдено баг: ОС, сервіс-пак, версія бібліотеки, назва функції та інше. У Description також вказуються кроки, дотримуючись яких можна відтворити ситуацію з виникненням помилки, отриманий результат (некоректний) та результат, що очікується після налагодження.
Прикріплений файл (Attachment) — скріншот, відео або будь-який інший документ, який допоможе продемонструвати причину виникнення помилки або пояснить, чому результат є некоректним.

Етапи оформлення баг-репорту

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

Перш ніж створювати новий баг-репорт, переконайтеся, що знайдену помилку вже не було задокументовано. Для цього виконайте його пошук за ключовими словами в потрібному проекті. Якщо такий звіт вже є, переконайтеся, що проблема в ньому описана повністю, і в разі потреби доповніть інформацію.
Якщо знайдений баг ще не був задокументований, починайте створення нового баг-репорту. Пам'ятайте правило: одна помилка – один репорт.
Складіть правильний заголовок баг-репорту. Він має бути коротким, і водночас повністю відбивати суть проблеми.
Опишіть проблему докладніше, вкажіть місце, де вона виникла, кроки, які призвели до її виникнення. Це буде Description.
Вкажіть отриманий результат, який є некоректним.
Вкажіть очікуваний результат роботи частини функціоналу. Якщо це можливо, прикріпіть посилання на специфікацію.
Вкажіть версію програмного забезпечення, в якій виявлено баг, а також версію оточення.
Прикріпіть файли, які допоможуть розробнику краще зрозуміти проблему: скріншоти, логи та інше.

Поширені помилки у складанні баг-репорту

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

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

Недостатній обсяг наданих даних. Іноді зафіксована проблема виявляється не при всіх значеннях, що вводяться, або не під будь-яким користувачем, що увійшов до системи, тому опис репорту повинен містити всю можливу інформацію про помилку з урахуванням різних факторів. В іншому випадку відповідальний розробник може відхилити баг, і QA-інженеру доведеться витрачати час на його повторне складання.
Не вказано отриманий та очікуваний результат. Коли розробник бере баг у роботу, він має чітко розуміти, який результат система виводить зараз, і що має бути виправлено у процесі доопрацювання — тобто, який очікуваний результат. Якщо ця інформація не вказана, програмісту доведеться витрачати свій час на її пошук, що уповільнює виправлення дефекту. Тому при складанні баг-репорту бажано вказувати посилання на пункт у вимогах, тест-кейс або аргументовану суб'єктивну думку тестувальника, якщо ситуація, що виникла, раніше не була задокументована.

Життєвий цикл бага

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

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

Як стати тестувальником

QA-інженер повністю відповідає за те, щоб кінцевий користувач отримав надійний продукт, який працює без збоїв та помилок. Якщо ви хочете освоїти професію тестувальника та побудувати кар'єру у сфері IT – приєднуйтесь до курсів SpaceLAB. У нас навчання проводиться безкоштовно, під кураторством досвідчених менторів, а найуспішніші студенти гарантовано отримують можливість працевлаштування в компанію AVADA MEDIA.