10 найчастіших помилок при оформленні баг-репортів

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

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

Багатьом слухачам може здатися складним або зайвим слідувати даній вимозі до опису баг-репортів. Але цей принцип допомагає коротко і повно описати суть помилки, де вона виникає і за яких умов. Даний принцип – це загальне правило, алгоритм складання опису помилки. Зазвичай, відсутність будь-якої частини (Що?, Де? або Коли?) робить опис менш інформативним.

Тему, опис і результати в баг-репортах в більшості випадків потрібно описувати, використовуючи Present Simple Passive Voice, так як в баг-репортах важливіше те, що відбувається з об'єктом, ніж той, хто виконує дію. Якщо курсант незнайомий з Passive Voice, потрібно вивчити правила його формування самостійно за допомогою інтернет-ресурсів або інших джерел. Одна з найпоширеніших помилок курсантів – неправильне формулювання пасивного стану («The button is not opened the page»). Важливо детально розібратися, як формулювати пасивний стан, щоб вживати його граматично правильно.

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

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

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

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

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

Ще одна поширена помилка. Щоб правильно побудувати речення для опису суті помилки, в ньому потрібно використовувати підмет і присудок. Не можна писати «Немає позначення обов'язкових полів на формі». Правильно буде описати так: «Відсутнє позначення обов'язкових полів на формі».

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

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

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