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

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

Як скласти баг-репорт, який позбавить команду зайвих зусиль, збереже гроші клієнту, а особисто тобі — нерви, і навіть покращить карму? Я — делівері директор і глава центру розробки 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. Орієнтуйся на структуру, а не на інструмент. Правильно розставляй акценти.

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

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

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось164
До обраногоВ обраному50
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Цікаво той факт, що особистий інші люди досвід люди сприймають як особистий виклик.
Дякую автору, за те що Він поділився особистим досвідом та думками

Дуже цікава і актуальна стаття! Дякую за детальне і зрозуміле пояснення!

Дуже класна та корисна стаття! Дякую!:)

Дякую за фiдбек

З одного боку якісна та дуже корисна інформація, але із свого більш ніж 15 річного досвіду у розробці комерційного ПЗ багато тверджень викливають питання. Наприклад, впевнений, що Priority — це не зона відповідальності QA. Наприклад, щось зовсім не працює у Сафарі на айфоні, але це 1% від усіх користувачів — то ж за правилами Priority буде Low, але бізнес знає, що ця фіча була зроблена для особливої групи користувачів, з яких 90% саме на айфонах. Тому правильний Priority стане Critical. І зовсім не можу погодитись із пропозицією перевіряти результат реєстрації у базі. Це правильно робити лише у тому випадку, якщо є «сторі» у якій написано, що «після успішної реєстрації у таблиці А має з’явитись новий запис». Тоді тестувальник посилається на цю сторі, та пояснює — що це не працює. Так саме писати щось у базу руками — це категорично НІ, бо чому QA вирішив, що це єдиний запис, що відбувається у результаті реєстрації? Можливо при правильному флоу додаються 5 записів у різні таблиці, а тестувальник додав лише один, що відкриває йому двері для ще сотні багів, які ніколи не відбудуться у реальному житті.

Дякую за фiдбек, але і я з свого досвіду не можу з вами погодитись, але це нормально як на мене. У кожного своя школа та своя правда тут, але я спробую відстояти ці пункти, що ви описали.

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

Що стосується Safari, то про нього в статті навіть немає згадки, а говоримо ми про chrome, який є одним за найпопулярніших браузерів. Але немає сенсу який браузер ми обговорюємо, бо я у статті казав про перевірку та підтвердження що дефект релевантний у любому браузері що ми підримаємо за вимогами, та й дефект цей не є браузерозалежним. Звідси й показники priority та severity

Ну а про базу, то я в цілому не можу прийняти, як QA старої закалки. QA, який буде тільки, як та мавпа зі статті тикати у UI без якогось вміння копнути глибче — поганий тестувальник, та не QA зовсім, на мою думку. Гарний QA буде або мати рацію як і в які таблиці потрібно додати запис для реєстрації юзера (камон, це базовий функціонал для подальшого тестування), або запитає на це девелопера, та зможе продовжити тестування, а не буду чекати на фікс багу, якщо є шанс на workaround

Але я не говорю, що це єдина істина. Може на ваших проектах ви не допускаєте QA до бази, та в них другий спектр задач. Все може бути

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

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

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

Ну да, в такому випадку є сенс. Дякую)))

Підсумуємо основні моменти:
Знайшовши дефект, не поспішай бігти заводити його в систему. Переконайтеся, що він відтворюється, а ти знайшов не лише наслідок, а й причину.
Рапортуй про те, що знайшов. Скриншоть падло, а не розказуй потім «а тама», «а здєся». Якщо вдалося відтворити — молодець, якщо не вдалося — напиши що робив, а потім перечитай та спробуй знову (пам′ять суттєво відновлює деталі, коли пишеш)

Заводячи дефект, пам’ятай, що твоя мета — максимально спростити іншим членам команди подальшу роботу з ним.
Твоя задача — задокументувати інцидент. Розробнику значно зрозуміліші можливі його причини та наслідки, так само як і частиною чого більшого він є. Розробнику краще відстрелити 100 гарно задокументованих зайвих інцидентів, аніж розібратися зі сміттям, що спотворює реальні дані.

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

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

Усі додані документи мають бути інформативними і не мають містити зайвої інформації.
А ви маєте бути експертом та замість отримувача вгадати, що інформативне, що ні, що зайве, а що корисне. Телепатія та дар передбачення — обов′язкові для QA. Так само як і прагнення до суіциду через харакірі, якщо не вгадав.

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

Орієнтуйся на структуру, а не на інструмент. Правильно розставляй акценти.
Плюс ще одна вимога: вміти зазирати в майбутнє. Саме так QA має дізнаватися, як правильно цього разу, і що має значення. Так само має бути ясновидцем, щоб передбачати, структура якої саме моделі має дефект, щоб прибрати інфу усіх інших моделей. А от інструмент і послідовність вказувати не треба — нащо, розробнику цілий день сумно та самотньо, тому він хоче весело витратити ще й вечір, намагаючись вгадати методику відтворення.

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

не знаю как у вас, а нас баг репорты выглядят так:
prnt.sc/g1h-Ix9MpFDY

достойно уважения :) мое почтение QA инженеру

на самом деле это баг репорт от нашего менеджера, но как же иногда хочется написать так же:)

Відповідь команди розробників:
— This f☆cking media we’re used to call a porn, there’s no language there. A tongue is.

Баг репортів, за які подякують, не буває. Бувають документовані баги від QA. В дуже кращому випадку бувають повідомлення від бета-тестерів. За усе інше можна отримати як мінімум невдоволення, як максимум — помсту.

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

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

Цю б статтю та нашим «QA — багиням» у вуха! У них найпопулярніший баг, який відкривають по 3 рази на день: «зависає спинер». Ну от «я натиснула — а коліщатко крутиться і нічого не відбувається». Жопаскрипт аджакс програма — помилки показувати не в моді, а у консоль зазирати дiвчатка не вмiють.
Від себе прошу обов’язково відкривати в браузері консоль і спробувати чи є помилки жабаскрипту чи помилки запитів на сервер. Знайдене QA повідомлення про помилку (наприклад текст 500 помилки з сервера) економить девелоперу години роботи!
Далеко не зайвим буває записувати відео. У модних Ангулярах або Реактах дуже часто щось «поморгає» і ховається через асинхронність, перегони та постійне перемальовування. Стоп-кадр допомагає зрозуміти, що відбувалося.
Ще корисно після виявлення бага зробити снепшот енвайроменту (віртуалки, бази) якщо можливо або хоча б не змінювати дані, на яких баг зарепродюсився. Найчастіше головна проблема девелопера — це зарепродюсити баг. На його локальній машині це може не вийти — і тоді він прийде бешкетувати на тесті. Якщо там те саме вже не відтворюється (оскільки QA змінив дані) — то девелопер баг просто поверне.
На гнилому ентерпрайзі я завжди вимагаю від QA докладно писати очікувану поведінку. Тому що хоч клієнт, хоч БА завжди описують у вимогах лише успішні сценарії. А хороший QA має тестувати і не-успішні. Ось напривлад: він відкрив дві копії сторінки і на обох змінює один запис і намагається зберегти. Припустимо на одній вилітає 500 помилка — баг. Але девелопер повинен розуміти, а що має бути? Просто зрозуміліший текст помилки? Чи помилки взагалі не повинно бути за принципом «хто останній — той тато»? І це робота QA уточнити вимоги (а можливо — завести баг на відсутність вимог!) та написати очікуваний результат.

Відчуваю усю боль через текст :) Дякую за розгорнутий команетар

Непогана стаття) Дійсно, треба додати пунктик що завжди треба перевіряти на дублікати, бо інколи баги повторюються з часом.
Напишіть ще щось про регресію і тест кейси:)

Дякую! Хто знає, може і напишу подалі. Хочу додати статей до нашої спільноти!

зайшла писати про тест-кейси, бо дуже треба)) а тут вже все є!

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

Навіть серед тих хто фіксає не всі можуть знайти причину).

Я б до статі добавив
— баг репорт має містити номер релізу де появилась бага (або хоча б чи репродюситься на проді). Бо якщо команда готує реліз і баг репродюситься на проді то пофіг на нього. А без такої інфи реліз відсовується через неважливі баги (бо якщо вони на проді і ніхто не жаліється => баги не важливі).
— при веб тестуванні завжди ранити дебаг режим браузера щоб можна було зберегти реквести/респонси або хоча б зробити скріншот нетворкінг таби. Це в більшості випадків дозволяє зрозуміти яи ще фронтент чи бекенд бага.
— уникати допилювань фіч через баги. Наприклад фіча полягала в можливості аплоадити файл. Узгодили що якщо файл завеликий то кидати бекенд ерорку «поганий інпут» і щось схоже виводити на фронті. Коли фіча готова і тестується, тестер заводить баг що еррорка не інформативна, перепитує РО чи треба це фіксати. РО підтверджує що треба фіксати, і ось замість імпрувменту в майбутньому ми отримуємо багу. Такого робити не треба. В той жеж час треба мати сміливість протистояти стандартному «так має бути», «ми так домовлялись», «апрувай бо завтра деплой» і т.п. Баланс тут в кожного проекту свій

Так я же в статті вказував номер релізу :) Даже у прикладах є. Інші пунктики — гарні доповнювання.

Порадьте що робити у ситуації коли в логах є явна помилка до прикладу завалився депозит а репродюснити немає змоги. Як би ви вирішували кейс?

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

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

Наче добрий допис, але є кілька зауважень. Цільова аудиторія — зовсім початківці, без жодного комерційного досвіду (треба це мати на увазі).

1. Радити лізти в базу, та не радити подивитись що там взагалі робиться у консолі — якось дивно. Та взагалі доступ до бази скоріш за все буде обмежен.
2. Нема золотого правила: «Шукай перед тим як створити новий»
3. Самарі повино відповидати на 3 питання: Що? Де? та за яких обставинах?
4. Якась дивна структура дескріпшена. Мені здається що повино бути: Steps to reproduce; ER; AR

Дякую за коментар. Радий, що доповідь сподобалась. Фібек це завжди домога наступним статтям :) За перевірка на дублікат «Шукай перед тим як створити новий» тисну руку, колега. А ось з іншими пунктами не можу не погодатись, а ні оскаржити, бо вони дуже залежні від проекту та процесів на ньому.

бо вони дуже залежні від проекту та процесів на ньому.

Якщо на проекті є документ, який фіксує проформу, то все інше непотрібно. Бо хтось вирішив що так треба. Рядовий мануал qa скорше нічого вже не зробить.
В усіх інших випадках — треба робити так як буде зручніше усім.

У випадку належного самарі (все зрозуміло) на перше що взертає увагу інжинер так це Steps to reproduce. Після того як всі степи пройшли, то мозок людини вимагає ER. Щоб зрозуміти як воно повино працювати. + відсікти кейси, коли ER суперечить інщім рекваертам. А вже після — час AR

а я ось посмію не погодиться. Допустимо самарі не вистачило, то тоді, якщо все грамотно описати, вистачить найчастіше AB щоб відтворити, і EB щоб зрозуміти, як потрібно бути. А кроки по відтворенню, це швидше для складних і заплутаних кейсів, або для джуників які ще не так поглунили у проект.

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

Отличная статья, большое спасибо за статью!

От себя еще добавлю интересное и не всегда очевидное наблюдение.
Баг-репорт читает как минимум 3 человека:
1)Сам qa который его пишет.
2)Дев который его фиксит.
3) QA(вероятнее всего тотже, что и на шагу (1)) который его верифицирует.
И если будете писать баг-репорты таким образом что через 2 дня не сможете по шагам его проверифицировать, то вы быстро прекратите писать баг-репорты))

Следует всегда помнить следующее:
«Не плюй в колодец, тебе с него еще пить» или же «Не плюй на качество баг репорта, тебе его еще верифицировать».

Все так! Хороший комментарий

Не плюй в колодец, твой труд не оценят. Лучше спрячь туда дохлую кошку, чтоб не заметили до релиза.
© команда розробників Дія

Було корисно та інформативно! Дякую!

Що ж за така команда у вас була яка писала такі репорти.... співчуваю

Чого тільку не буває, хтось міг дістатись у спадок, когось перевели до команди та погано співбесідували на вході. Наше завдання виправити помилки та виховати грамотних інженерів

Підписатись на коментарі