Баг-репорт, за який вам подякують

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

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

Прочитати статтю буде корисно і QA-інженерам, які безпосередньо створюють баг-репорти, і розробникам, які ці репорти читають і виправляють баги. Деякими рекомендаціями ти, напевно, зможеш поділитись i зі своїми колегами.

В чому, власне, проблема

Скажи, друже QA-інженере, чи тобі колись повертали баг-репорт, пославшись на те, що описаний тобою дефект — це зовсім не дефект, і відтворити його неможливо? Чи, може, ти часом відчував потилицею крижані погляди колег, які виправляють знайдені тобою помилки?

А тобі, друже розробнику, не доводилося читати опис дефекту «Функціонал працює неправильно»? Ось такий, лаконічний: без пояснень, кроків відтворення та деталей перевірки? Зате зі скріншотом двох робочих моніторів з десятками відкритих додатків і вкладок у браузері?

Невже тобі жодного разу не хотілося запропонувати QA-інженеру покинути команду, де йому не раді, і повернутись на такі популярні наразі курси «Увійти в айті за 3 місяці»?

Якщо принаймні одне з запитань нагадало тобі випадок з практики, тобі варто читати далі. Для тих, хто здивувався, чому це раптом людині з делівері кортить розповідати про досить просту і дуже конкретну річ, та ще й не з зони своїх робочих завдань, поясню. Протягом п’яти років я працював QA-інженером, потім — лідом команди тестування з 15 осіб, майже десять років викладав QA, випустивши як педагог і ментор не одну сотню хлопців та дівчат, що вже давно працюють у DataArt та інших компаніях. До того ж я веду тісно пов’язаний з тестуванням телеграм-канал «Уютная Галера».

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

Ефективний баг-репорт. Щоби що?

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

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

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

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

• Економія грошей клієнта. На виправлення добре описаного дефекту розробник витратить значно менше часу. Для цього баг-репорт має дати йому цілковите розуміння проблеми: добре, якщо вже за коротким описом дефекту зрозуміло, що, де та як виправляти.
• Прискорення процесу. Зайві пів години, витрачені на дослідження і документування дефекту, позбавляють команду необхідності ставити додаткові запитання, виключають пінг-понг дефектом між різними фахівцями і знижують кількість часу на перевірку після виправлення бага.
• Збереження стосунків. Хоча наука довела, що нервові клітини здатні відновлюватися, проте чи варто їх витрачати на роботі, до того ж на сварки на кшталт «дефект / не дефект» усередині команди?
• Поліпшення карми. Набагато спокійніше жити, коли ніхто не кидає на тебе злих поглядів, коли ніхто з твоєї команди не обговорює тебе в курилці, щобільше, не розуміє, за що своїх тестувальників лають програмісти з інших проєктів. Зрештою, грамотно складений баг-репорт — цегла репутації всієї професії QA-інженера, найнадійніший спосіб змусити навіть найзарозумілішого розробника забути огидне (в робочому контексті) слово «мавпа» (ми таке ставлення принципово не вітаємо і засуджуємо, але визнаємо, що не всі тестувальники заслуговують лише на добрі слова).

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

Структура баг-репорту, не залежна від інструментів

Знайдені дефекти ми враховуємо за допомогою різних defect management tools. На ринку представлено десятки таких інструментів, від не зовсім профільних, як-от Trello, Notion або Asana, до професійних: Jira, Kualitee, Bugzilla і навіть Github.

Особливо перекручені методи роботи з дефектами, наприклад, у таблицях Excel і Google Docs, я враховувати відмовляюся. Втім, вибір інструменту не впливає на структуру опису дефекту — правильний підхід робить тебе незалежним від механізму фіксації дефектів. Ще раз: важливо не де, а як.

Структура баг-репорту має виглядати так:

1. ID дефекту (якщо інструмент не налаштовано на автоматичну видачу ID).
2. Summary — короткий опис дефекту.
3. Impact — рівень впливу дефекту на функціонал і бізнес (складається з Severity і Priority).
4. Defect Description — розгорнутий опис дефекту. Зазвичай складається з: опису оточення, де знайшли дефект, зокрема версію продукту; отриманого результату або поточної поведінки дефекту; очікуваного результату або очікуваної поведінки програми після виправлення; кроків по відтворенню з прикладами використовуваних даних, плюс, у разі необхідності, скріншотів і логів.
5. Additions — додаткова інформація, що може стати у пригоді при роботі з дефектом. Наприклад, можна додати ключові слова, що вказують на функціонал/компонент, якого він стосується: «Registration Feature», «Login Epic» або «UI component», «API component», «DataBase component» тощо.

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

Ефективний баг-репорт. Від теорії до практики

Тепер наповнимо цю структуру реальними прикладами.

Припустимо, в нас є невеликий вебпроєкт під назвою «IT Сourses: 3 місяці — і вперед!». Наразі ми тестуємо його версію v0.8.03.124. У проєкті можна створити користувача, залогінитись і публікувати від його імені якісь повідомлення на спеціально відведеній сторінці. Перший знайдений нами дефект виглядає так:

— Ми змогли зареєструвати користувача, але під час спроби залогінитися під його ім’ям отримуємо повідомлення про помилку «неправильне ім’я та пароль».

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

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

Заходимо в базу і бачимо, точніше, не бачимо взагалі жодного запису про наших користувачів: ані про першого, на якому помітили дефект, ані про другого, якого створили при спробі відтворити дефект. Озброєні новим знанням, для заспокоєння душі намагаємося зареєструвати третього користувача. Але й про нього запис у базі відсутній.

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

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

Summary

Короткий опис, завжди складається у безособовій формі, за визначенням не може бути довгим і має містити лише основні деталі. Ідеальний баг-репорт — той, подивившись на summary якого відразу зрозуміло, що, де та як виправляти. Для наочності спочатку можна додати компонент/функціонал, до яких належить знайдений дефект та, якщо проблема вимагає негайної уваги, слова «URGENT» або «CRITICAL».

❌ Приклад поганого summary: «Проблема з реєстрацією».
✔️ Приклад допустимого summary: «При реєстрації нового користувача запис у базі даних не створюється».
✅ Приклад ідеального summary: «Реєстрація: під час реєстрації нового користувача запис у базі даних не створюється».

Impact

Нагадаю, що він складається з двох полів: Severity та Priority.

Severity — показник того, як дефект впливає на функціонал нашого продукту:

• Urgent/Critical — цілковита поломка продукту, ризик втрати користувацьких даних, проблеми безпеки тощо.
• High — поломка середньозначного функціоналу, помилка роботи пріоритетних операцій тощо.
• Medium, low — незначні огріхи в UI, поломка малозначного функцiоналу, corner cases, помилки в назвах тощо.

Важливо пам’ятати, що рівень severity дефекту зазвичай не змінюється після того, як баг-репорт опинився у системі.

Priority — рівень впливу дефекту на бізнес замовника та показник того, наскільки швидко його потрібно усунути:

• Urgent/Critical — необхідний терміновий фікс, баг блокує подальше тестування, надто негативно впливає на бізнес, веде до великих фінансових втрат.
• High — дефект має бути усунено до наступного релізу.
• Medium — добре було б пофіксити, коли буде можливість.
• Low — якщо ми відкладемо ремонт цього дефекту на невизначений термін, нічого поганого не станеться.

Priority може змінюватись у процесі проєкту, так само, як пріоритети нашого клієнта.

Повернемося до дефекту, який ми знайшли. Severity ставимо на рівень High — сайт відкривається та працює, а ми фактично втратили нехай і значущу, але лише частину функціоналу. Priority залежить від пріоритетів замовника, але без додаткових ввідних даних я б також ставив High (допустимо Medium, якщо в нас є workaround для подальшого тестуванння. Наприклад, створити запис у базі даних самостійно).

Defect Description

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

• Environment.

❌ Поганий приклад: Google Chrome.
✔️ Допустимий приклад: Google Chrome, version: 100.0.4896.88, project version: v0.8.03.124.
✅ Ідеальний приклад: Google Chrome, version: 100.0.4896.88, browser language and locale: English, project «IT courses: 3 місяці — і вперед!», v0.8.03.124.

• Component: Реєстрація користувача.

• Actual Behaviour.

❌ Поганий приклад: реєстрація не працює.
✔️ Допустимий приклад: реєстрація не проходить через відсутність запису в таблиці «users».
✅ Ідеальний приклад: під час реєстрації нового користувача через UI отримуємо повідомлення про вдало створений новий обліковий запис, але в базі, у таблиці «users» відповідний запис не створюється.

• Expected Behaviour.

❌ Поганий приклад: реєстрація працює.
✔️ Допустимий приклад: реєстрація через UI створює запис у таблиці «users».
✅ Ідеальний приклад: при реєстрації нового користувача через UI отримуємо повідомлення про вдало створений обліковий запис, водночас у базі, у таблиці «users» створюється запис із даними, що відповідають введеним під час реєстрації.

• Steps to reproduce.

❌ Поганий приклад: зареєструй користувача та спробуй залогінитись.
✔️ Допустимий приклад:

• реєструємо користувача через UI;
• перевіряємо базу даних і таблицю «users» на запис про нового користувача.

✅ Ідеальний приклад:

• заходимо на сайт «IT courses: 3 місяці — і вперед!»;
• реєструємо нового користувача, заповнивши необхідні поля (e. g. email: [email protected] / password: Qw?102938 / nickname: andrey, див. скріншот 1);
• перевіряємо повідомлення про вдалу реєстрацію;
• відкриваємо базу даних (можна додати, під яким логіном ми до неї переходимо);
• переконуємось у відсутності нових записів у таблиці «users» (див. скріншот 2).

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

Attachments:

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

• Скріншот 2, на якому можна побачити результати роботи запиту до бази даних або вміст відповідної таблиці «users».

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

Тепер повертаємось на UI нашого сайту, пробуємо залогінитись під логіном і паролем цього користувача. І знову успіх, щоправда, невелику проблему ми таки помітили. Кнопка «Login» мала змінитися на кнопку «LogOut», але цього не сталося. Так само як і минулого разу, не поспішаємо вносити дефект, не уточнивши деталі. Спершу спробуємо кнопку натиснути! Натискаємо і бачимо, що користувач вийшов з облікового запису, значить, кнопка працює, хоч і не змінює назви.

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

Summary:

Impact:

• Оскільки функціонал працює справно і зачеплений, лише UI:

• Терміновості у виправленні теж немає, тестування не заблоковане. З погляду бізнесу імпакт також не є критичним:

Environment:

Description:

Attachments:

Зв’язок з компонентами/функцією:

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

Висновки. Ефективні, як наш баг-репорт

Підсумуємо основні моменти:

1. Знайшовши дефект, не поспішай бігти заводити його в систему. Переконайтеся, що він відтворюється, а ти знайшов не лише наслідок, а й причину.
2. Заводячи дефект, пам’ятай, що твоя мета — максимально спростити іншим членам команди подальшу роботу з ним.
3. Хороший баг-репорт не викликає додаткових запитань. В ідеалі — вже його summary пояснює, що зламалося, де зламалося і як це полагодити.
4. Уся інформація, представлена ​​в баг-репорті, не має бути перевантаженою деталями, але водночас має бути зрозумілою навіть для найменш досвідченого члена команди.
5. Усі додані документи мають бути інформативними і не мають містити зайвої інформації.
6. Увесь опис дефекту складається в безособовій формі, наводити варто лише факти, прибравши з тексту всю воду.
7. Орієнтуйся на структуру, а не на інструмент. Правильно розставляй акценти.

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

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