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

Одним з цікавих методів навчання є написання шкідливих порад. У нашому блозі міститься багато статей про те, як правильно і добре складати звіти про помилки, які атрибути вони повинні містити і яким вимогам відповідати. Але в даній статті ми розглянемо те, як робити не треба, і які помилки часто допускають тестувальники-новачки на проєктах.

Часті помилки при оформленні баг-репортів

1. Використання принципу «Що? Де? Коли?» при формулюванні теми баг-репорта в тих випадках, коли частини «Де?» або «Коли?» можуть бути пропущені.

Насправді, в темі обов'язково слід відповісти тільки на одне питання «Що?». В окремих випадках відповіді на питання «Де?» і «Коли?» можуть бути втрачені, але тільки в разі, якщо вони дійсно не несуть ніякої інформаційної цінності. Тобто, при написанні теми слід дотримуватися формату запису «Що? Де? Коли?», завжди дотримуючись цієї послідовності, але дотримуватися також здорового глузду, іноді забираючи відповіді на ті питання, які порушують лаконічність, дублюють інформацію або не важливі по своїй суті в конкретній ситуації.

2. Відсутність префікса в темі баг-репорта при кросплатформеному тестуванні на мобільному пристрої або при тестуванні ігор.

Що таке префікс? Все дуже просто – це те, що потрібно писати перед темою, коли тестується додаток/сайт на мобільному девайсі або ігри: назва браузера, модель пристрою, версія операційної системи, локалізація гри (наприклад, [Mobile] iOS або iPad 2. ZH. Квест 356). Подивившись на префікс, відразу можна зрозуміти в якому оточенні тестується програмний продукт.

3. Надмірність тексту в передумовах.

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

4. Відсутність важливих додаткових відомостей або кроків/дій для відтворення бага.

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

5. Не вказано або вказано з помилкою посилання на головний домен в першому кроці.

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

6. У кроках вказані посилання на конкретні сторінки сайту.

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

7. Детальний опис помилки в останньому кроці.

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

8. Один із результатів описано як заперечення іншого.

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

9. Зайві елементи на скріншоті (відео) і відсутність потрібних.

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

10. Присутність сторонніх звуків у відео.

Для зняття відео з екрану необхідно використовувати спеціальні програми. Одна з частих помилок – це сторонні звуки в відео. Вирішується вона дуже просто – необхідно в налаштуваннях вимкнути запис звуку. Тепер при перегляді відеофайлу вся увага буде приділятися тільки помилці.

11. Відображення сторонніх повідомлень на скріншоті або відео (месенджери тощо).

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

12. Наявність простого скріншота замість складного для підтвердження функціонального бага.

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

13. Присутність декількох акцентів на скріншотах.

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

14. Виділення помилки на скріншоті кольором, який зливається з дизайном продукту.

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

15. Відсутність відео крешу з девайсів і файлу з логами у вкладеннях.

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

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