Часто виникають ситуації, коли на сайті зустрічається один і той же баг на різних сторінках. Якщо описувати кожен дефект окремим звітом – можна зайняти багато зайвого місця в баг-трекері, заплутати себе і розробників, або ж зіпсувати всю статистику по дефектах.
Однотипні баги в різних місцях
Під час тестування як сайтів, так і додатків можна зустріти подібні дефекти. Розглянемо деякі ситуації докладніше на прикладах.
- Після зміни локалізації деякі елементи не перекладені.
Як ми бачимо на скріншоті, після зміни мови сайту на українську, назви розділів і текст банерів продовжують відображатися англійською. Це вдалий приклад бага локалізації. В даному випадку краще буде згрупувати елементи в окремі блоки, наприклад: блок меню і блок з банерами. Далі оформити по одному баг-репорту на кожен блок:
- Назви розділів «Women», «Dresses» і «T-Shirts» не перекладені на головній сторінці сайту після зміни мови сайту на українську.
- Текст банерів «3 Days sale» та «Only online summer» не перекладений на головній сторінці сайту після перемикання мови сайту на українську.
Якщо елементи, для яких дефект відтворюється, розташовані на певній відстані один від одного і не можуть бути згрупованими, можна завести один звіт про помилку для одного такого елемента і в поле «Детальний опис» (Description) зазначити інший елемент з таким же багом на даній сторінці.
Важливо! Якщо таких елементів з однотипними багами декілька або досить багато, то їх перелік зазначається в розділ «Додаткова інформація» (Additional information).
Наприклад:
Summary: Курсор миші не змінюється на «Вказівник» на головній сторінці сайту після наведення на кнопку «Зворотний зв'язок».
Description: Курсор миші не змінюється на «Вказівник» на головній сторінці сайту після наведення на кнопку «Зворотний зв'язок». Дефект також відтворюється для кнопки «Додати в кошик».
або
Summary: Курсор миші не змінюється на «Вказівник» на головній сторінці сайту після наведення на кнопку «Зворотний зв'язок».
Description: Курсор миші не змінюється на «Вказівник» на головній сторінці сайту після наведення на кнопку «Зворотний зв'язок».
Additional information: Дефект також відтворюється для кнопок «Додати в кошик» та «Залишити відгук»
- Текст виходить за межі відведеної області.
На скріншоті видно, що текст кнопок «Toista panos» і «Toista panos x2» виходить за межі відведеної області. В даному випадку не варто оформлювати окремі баг-репорти на кожен окремий елемент. Краще завести один баг-репорт, в якому перерахувати знайдені елементи з дефектами:
- Текст кнопок «Toista panos» та «Toista panos x2» виходить за межі відведеної області на екрані «Table» після перемикання мови на «Finnish».
Якщо дефект відтворюється для декількох мов, або для всіх крім однієї, то в розділі «Additional information» їх необхідно перерахувати або коротко зазначити одним реченням дану інформацію.
Або ж якщо баг відтворюється тільки для однієї мови, в такому випадку слід зазначити вибрану мову в «Передумови» (додається в розділі «Кроки відтворення» (Steps to reproduce) перед кроками). Розділ «Додаткова інформація» можна заповнити за бажанням.
Наприклад:
Summary: The «Details» value field is overlapped by the «Round ID» text on the «Hand History» screen.
Description: The «Details» value field is overlapped by the «Round ID» text on the «Hand History» screen.
Additional information: The issue is reproduced with all languages, except English.
або
Summary: The «Details» value field is overlapped by the «Round ID» text on the «Hand History» screen.
Description: The «Details» value field is overlapped by the «Round ID» text on the «Hand History» screen.
Preconditions: English language is set on the site.
Steps to reproduce: 1. Open the site...
Additional information: The issue is reproduced only with English language.
Далі розглянемо одну з типових помилок, яку допускають новачки. Зверніть увагу на розташування кнопки «Кошик» – елемент водночас не вирівняний за вертикаллю і горизонталлю. Так і треба писати в звіті про помилку:
- Кнопка «Кошик» не вирівняна за вертикаллю і горизонталлю на головній сторінці сайту.
Ми вмістили коротко і ясно сенс всього баг-репорта в одному реченні. Не варто заводити звіти про помилки окремо на вирівнювання за вертикаллю і окремо на вирівнювання за горизонталлю.
Що робити, якщо баг зустрівся в різних браузерах?
Дуже часто бувають ситуації, коли знайдений дефект відтворюється в різних браузерах або на різних операційних системах. Що ж, власне, робити, якщо баг зустрівся на різному оточенні?
Необхідно перерахувати в одному баг-репорті всі браузери / пристрої / ОС , на яких відтворюється баг в окремому полі «Additional Info» або «Environment»(якщо воно є).
Наприклад:
Additional info:
Environment:
Safari 4.1.3
Chrome 83.567 (56)
Якщо однотипний баг зустрічається в декількох місцях – рішення також максимально просте. У розділі «Additional Info» вказується перелік сторінок, на яких був знайдений дефект, наприклад, при дефектах перекладу елементів сайту на вибрану мову.
Наприклад:
Кнопка «Вхід» не має перекладу і відображається як «Enter» на сторінках «Реєстрація», «Меню» і «Пошук». На інших – відображається перекладеною. Якщо в кроках ми вказали, як відтворити баг, скажімо, для сторінки «Search», тоді в «Additional Info» пишеться:
The bug is also reproduced on the «Registration» and «Menu» pages.
Варто розуміти, що можна об'єднати кілька однотипних дефектів в один, але найчастіше один баг-репорт повинен повідомляти про один баг.
Освіжимо в пам'яті основні терміни для опису багів:
Баг – це невідповідність фактичного результату виконання програми очікуваному результату. Дефекти виявляються на етапі тестування програмного забезпечення, коли тестувальник проводить порівняння отриманих результатів роботи програми (компонента або дизайну) з очікуваним результатом, описаним в специфікації вимог.
Баг-репорт – це документ, що описує ситуацію або послідовність дій, яка призвела до некоректної роботи об'єкта тестування, із зазначенням причин і очікуваного результату.
Баг-трекер – прикладна програма, розроблена з метою допомогти розробникам програмного забезпечення враховувати і контролювати помилки, знайдені в програмах, побажання користувачів, а також стежити за процесом усунення цих помилок.
Атрибути бага в баг-трекері:
ID – це унікальний ідентифікатор бага в баг-трекері. Автоматично присвоюється системою.
Summary – короткий і лаконічний опис бага, що відповідає на питання «Що сталося, де сталося і за яких умов?».
Наприклад: The «404 Page not Found» error message is shown (що?) on the «Contact us» page (де?) after clicking the «Contact us» link (коли?).
Тобто опис бага має бути таким, щоб програмісту можна було не відкривати баг-репорт, а відразу виправляти баг. Але частіше трапляються все ж складні баги, які вимагають опису додаткових дій та роз'яснень. Тобто тільки за темою баг-репорта може бути важко зрозуміти проблему та потрібна додаткова інформація, як баг відтворити та як насправді повинно бути. Далі розглянемо наступні атрибути баг-репорта.
Preconditions – в даному полі пишеться зазвичай те, що потрібно зробити перед виконанням кроків відтворення. Також, можна вказати дані для відтворення (логін і пароль, посилання, ID продукту та інше). Наприклад, потрібно створити користувачів з різними ролями, які потрібні для відтворення цього бага.
Якщо суть бага в тому, що нещодавно створений адміністратор не може увійти в адмін-панель з валідними даними, а старі адмін-користувачі можуть, то в це поле слід написати, що потрібно створити нового адмін-користувача.
Так як кроки створення адміна – не впливають на суть цього бага, то цю дію можна винести в Preconditions. Наприклад: «A new admin account is created».
Steps to Reproduce – поле використовується для опису кроків, необхідних для відтворення даного бага.
Наприклад:
- Open the login page of the admin panel.
- Enter valid credentials into the «Username» and «Password» text fields.
- Click the «Sign in» button.
Тобто в цьому атрибуті описуються детальні кроки до того моменту, коли баг буде відтворено. Після останнього кроку ми повинні побачити той результат, який і є багом в даній ситуації.
Actual Result – описує, який результат був отриманий після виконання останнього кроку. Наприклад, це може бути описано наступним чином:
The «You have entered incorrect user or password» message is displayed on the login page after entering valid credentials
Expected Result – правильна поведінка системи після виконання останнього кроку.
На перший погляд здається, що даний атрибут не є важливим. Насправді робота системи може виконуватися правильно, але не відповідати заявленим вимогам, які описані в документації або надані замовником. Тому і потрібно вказувати очікуваний результат роботи системи.
Priority – слугує для визначення пріоритету бага, зазвичай виставляється менеджером проєкту, таким чином визначаючи першочерговість виправлення дефекту на тлі інших.
У різних баг-трекерах пріоритетність може визначатися різними рівнями (від «Immediate» до «Low», або цифрами від 1 до 4), принцип від найвищого пріоритету до нижчого. У деяких трекерах може зовсім і не бути такого поля (наприклад, Pivotal tracker).
Severity – вказує на серйозність помилки з точки зору впливу на роботу програмного забезпечення. Існують різні класифікації серйозності бага. Далі розглянемо один із різновидів классифікацій серйозності бага:
- Blocker. Баг блокує подальшу роботу програми або блокує подальше тестування. Наприклад, після створення користувача, з існуючим ім'ям не можна увійти в систему будь-яким користувачем, так як відображається SQL помилка на головній сторінці, що не дозволяє увійти в систему.
- Critical. Баг має суттєвий вплив на роботу програмного забезпечення, але не блокує його роботу. Наприклад, користувач може увійти в систему без введення пароля.
- Major. Баг має незначний вплив на роботу програмного забезпечення. Наприклад, кількість записів підраховується невірно в списку записів.
- Minor. Баг не впливає на функціонал програмного забезпечення. Наприклад, граматична помилка в назві елемента.
Як і в випадку з Priority, в різних баг-трекерах рівні серйозності можуть бути різними, але всі вони відображають вищевикладену суть.
Слід зазначити, що в багатьох випадках Severity бага буде приблизно дорівнювати його Priority. Але це не завжди так.
Наприклад:
- Логотип компанії на головній сторінці відображається з орфографічною помилкою або не відображається зовсім. Такого роду дефект не робить ніякого впливу на функціонал сайту, але з точки зору бізнесу – це дуже серйозно. У підсумку, маємо найнижчу серйозність і найвищий пріоритет.
- Відображається помилка 404 після переходу в один з розділів сайту. Здавалося б, необхідно встановлювати максимальні Severity і Priority. Але менеджер проєкту два дні тому повідомив, що в поточній ітерації робіт виправлення в тому функціоналі не планується, тому що є завдання більш важливі. У підсумку, маємо Severity = Blocker, але Priority = Low.
Assignee – в цьому полі вказується відповідальний за виправлення даного бага. У більшості ситуацій призначається менеджер проєкту, який вже розподіляє баги далі, або розробник, який відповідає за секцію, в якій був знайдений баг.
Status – статус за замовчуванням автоматично виставляється як «Новий» або «Відкритий». Далі може змінюватися розробником, тестувальником або менеджером проєкту в залежності від того, на якій стадії знаходиться баг.
Також, до баг-репорту потрібно в обов'язковому порядку додати скріншот/відео, які показують проблему. При цьому, потрібно пам'ятати, що баг повинен бути описаний так, щоб розробник міг його відтворити і без перегляду вкладення. Це пов'язано з тим, що бувають випадки, коли виникають проблеми при спробі перегляду вкладення (повільний Інтернет, обмежений трафік, перебої в роботі сервісу). Якщо дефект описаний неналежним чином, це заблокує роботу розробника щодо усунення помилки.
