Bug report та дебаг: як навчитися знаходити і виправляти власні помилки в коді

Жучок в коді. І це не про комаху, а про той самий «баг», якого всі бояться. Але він завжди з’являється, і це нормально. Важливо знати, як писати bug report, як працювати з цим документом і виправляти помилки в коді, спираючись на дані від тестувальника. Розберемо, як складати грамотний bug report.

Що таке bug report і навіщо він потрібен

Тестувальник досліджує код і знаходить помилку. Як йому донести до розробника, що сталася ця помилка? А як розробнику швидко зрозуміти, що саме потрібно виправляти та де потрібно шукати «жучка»?

Для цього й існує bug report. Це структурований за певними правилами звіт, мета якого допомогти швидко виявити проблему і знайти рішення. 

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

Навіщо потрібен bug report

«Не працює функціонал», «Тут щось зламалося, не відкривається». Уявіть, якщо вам, як розробнику, поставили таке завдання. Незрозуміло, що робити? Ось саме. Для цього і потрібен bug report. Якщо точніше, цей документ дозволяє:

• зафіксувати проблему, щоб вона була точно вирішена і не загубилася;
• визначити серйозність багу і пріоритет вирішення завдання;
• зекономити час розробників на пошук причини та розв’язання проблеми;
• підтримувати проєкт в технічно робочому стані.

Баги є і будуть завжди. Питання тільки в тому, як швидко їх вдасться вирішити. Для цього потрібен bug report і грамотна з ним робота.

Як скласти bug report, щоб швидко розв’язувати технічні проблеми

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

Структура bug report

Правильна структура — запорука успішної роботи всієї команди. Дотримуйтесь базових правил структури:

1. Чітко і строго сформульована тема. Не просто «не працює кнопка», а конкретно: «При натисканні з телефону на кнопку не відбувається ніяких дій». В ідеалі використовуйте формулу: Що-Де-Коли. Що відбувається, де саме, коли (в який момент).
2. Опис bug report. У декількох реченнях опишіть ситуацію. Уявіть, що ви пишете людині, яка абсолютно не знайома з проєктом. Чи зрозуміє вона, про що саме ви написали? Приклад: «На телефоні Xiaomi на сторінці товару при натисканні на кнопку «Купити» нічого не відбувається. Немає сповіщень, інформації, чи додався товар до кошика. Я не розумію, що мені далі робити на сторінці і як продовжити покупку». 
3. Покроковий шлях. Опишіть свій шлях, щоб інша людина могла повторити цей баг. Покроково. Що і в якій послідовності ви натискали й куди заходили. В ідеалі розробник повинен повторити шлях і потрапити на цей же баг.
4. Очікуваний результат. «Чекаю, що кнопка буде працювати» — це не очікуваний результат для bug report. Опишіть, що саме повинно відбуватися після вирішення багу. У нашому прикладі так: «Після натискання на кнопку «Купити» спливає поп-ап вікно, в якому написано, що товар доданий до кошика. Там є 2 кнопки: перейти до оплати та повернутися до товарів». 
5. Технічні атрибути. У bug report потрібно прописати всі технічні моменти завдання. Дані про спринт, середовище розробки, операційну систему, яка використовувалася при виявленні багу. Технічні описи допоможуть якомога швидше визначити баг і вирішити його.
6. Додаткові дані. Допоможуть скриншот, запис екрана, описані деталі або інші дані, які прискорять процес. Щоб зібрати їх, поставте себе на місце людини, яка буде читати bug report. Ви зможете все зрозуміти, якщо вас вирвати з контексту проблеми? Якщо так, це хороший bug report.

Це «Золота структура» баг репорта. Але можуть бути нюанси. Звертайте увагу на вимоги, викладені у вашій компанії.

Що важливо врахувати при роботі з bug report

В одному bug report — одна проблема. Нерідко виявляється відразу кілька багів в одному місці. Але кожен репорт повинен бути присвячений строго одній проблемі. Інакше почнеться плутанина.

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

Уникайте зайвої емоційності. Не потрібно писати, що «все пропало». Голова повинна бути холодною. Чітко і по суті. Інформація повинна бути детальною, але лаконічною. Ніхто не хоче читати кілометри тексту. 

Об’єктивність — ваш друг. Писати щось на кшталт «На мою думку» або «Мені здається» — погана ідея.

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

Підпишіться на наш Ютуб-канал! Корисні відео для програмістів чекають на вас! YouTube

Оберіть свій курс програмування! Шлях до кар’єри програміста починається тут! Подивитись

Висновок

Складання bug report не вимагає особливих навичок. Робіть документ таким, щоб він був зрозумілий. Якщо ви розробник, просіть колег складати bug report за принципом, описаним у статті. Тоді ви зможете швидко знаходити та виправляти власні помилки в коді.