Без сумніву, хороший баг-репорт – це документ високої якості. Написання якісного баг-репорта – це важливе завдання, адже саме баг-репорт буде основною точкою комунікації між тестувальником, розробником і менеджером проєкту. Добре написаний баг-репорт не тільки створить хороші взаємини між вами і розробниками, але і збереже ресурси компанії на роботу з ним.
Крім іншого, якісний баг-репорт повинен містити правильно написану тему (Summary). Як правило, Summary складається зі 150 символів або менше. Важливо переконатися, що Summary повністю відповідає на питання: що є проблемою? де і коли проблема відтворюється?
Також важливо пам'ятати, що під час опису Summary необхідно точно вказувати суть проблеми, – іншими словами, що саме працює НЕ ТАК . А тому не потрібно використовувати слова, які опишуть проблему абстрактно, без конкретизації, наприклад: нічого не відбувається, некоректно/коректно відображається, невірно/вірно працює, тощо.
Приклади неправильного опису:
- Нічого не відбувається після переходу на сторінку.
- Некоректно відображається розділ «Про компанію».
В описі бага, таким чином, абсолютно незрозуміла суть і, відповідно, визначити, на що слід звернути увагу і що саме необхідно виправити, буде складно.
Робота програміста і тестувальника – комплексний і взаємопов'язаний процес. Дуже часто баги, заведені тестувальником, «на ходу» виправляються розробниками. Тому «незрозуміло» описаний баг призводить до більшої витрати часу на його розуміння і відтворення і, як наслідок, втрати бюджетних коштів.
Для написання якісного Summary існує наступний алгоритм:
- Зрозуміти суть проблеми. Перед написанням Summary, необхідно, щоб у тестувальника було чітке розуміння того, у чому помилка.
- Детально описати помилку, беручи до уваги всі деталі її відтворення.
- Забрати зі сформульованої теми все зайве (умови не обов’язкові для відтворення помилки), уточнити важливі деталі.
- Дотримуватись принципу «Що? Де? Коли?» у реченні.
- Перевірити речення на відповідність до граматичних правил мови, якою написаний Summary
- Скоротити довжину речення, у випадку, якщо воно вийшло занадто довгим. Можна використовувати синоніми, скорочення або загальноприйняті абревіатури.
Розглянемо приклади правильного оформлення Summary:
- Відображається пуста сторінка у розділі «Наші проєкти» після натискання на кнопку «Наші проєкти».
- Кнопки навігації не відображаються у розділі «Про Компанію».
Але безумовно, в процесі тестування, іноді знаходяться баги, які не можна описати явним способом:
Додаток «Калькулятор» проводить неправильні розрахунки під час різних арифметичних дій.
У такому випадку досить складно визначити, в чому саме баг. Тестувальнику лише видно, що отриманий результат явно відрізняється від очікуваного. Тому, в таких випадках, баг описується в «глобальному» сенсі. Але однозначно зрозуміло, що проблема прихована в якійсь частині коду, яка впливає на кінцевий результат. Через це в такому баг-репорті допускається використання тих самих «заборонених слів».
Крім цього, ми можемо більш детально описати цю проблему у розширеному описі.
Наприклад, в темі і фактичному результаті ми вказуємо «Повідомлення про помилку не з'являється в полі введення поштової адреси після введення невалідних значень».
А в описі вказуємо, що дана ситуація відтворюється під час підтвердження з порожнім полем, після введення поштової адреси без символу «@» або без використання доменного імені.
Таким чином, ми не розширюємо тему бага, але в той самий час уточнюємо, в яких умовах баг відтворюється.
Також не забуваємо, що під час написання баг-репортів прийнято у фактичному результаті вказувати те ж саме, що і в Summary, а в очікуваному – що повинно відображатися на думку тестувальника. У описі результатів використовується те ж правило, що і у оформленні поля Summary (за принципом Що? Де? Коли?).
Зразки оформлення правильного Очікуваного результату:
- Відображається контент у розділі «Наші Проєкти» після натискання на кнопку «Наші проєкти».
- Відображаються кнопки навігації у розділі «Про компанію»
Часто виникає ситуація, що під час написання чекліста допускається використання некоректних слів, а під час написання баг-репорта – ні.
Різниця полягає у тому, що під час написання чекліста можна посилатись на надані макети продукту. Але часто у процесі розробки дизайн додатку або сайту може змінюватися, тому конкретизація місцезнаходження секції буде йти лише на шкоду.
Наприклад, опис «Секція «Продукти» відображається в правій верхній частині екрана».
Якщо після її перемістили у ліву частину, то тестувальник вважатиме це багом.
А без конкретизації досить буде звіритися з актуальним макетом для підтвердження правильності розташування секції. Тому опис «Секція «Продукти» коректно відображається на екрані» допустимий.
Не потрібно порівнювати чекліст і баг-репорт по правильності опису. Це різні документи, які виконують свої поставлені завдання. Те, що працює для одного, абсолютно недопустиме для іншого. Завдання чекліста – описати поведінку максимально коротко.
У баг-репорті потрібно точно вказати проблему на момент тестування.
Опис «Секція «Продукти» відображається некоректно на сторінці» не описує суть проблеми.
Завдання хорошого баг-репорта – описати проблему максимально повно і зрозуміло не тільки для іншого тестувальника, а й людини, яка абсолютно не знайома з продуктом.
Саме тому тут важливо вказати у чому саме проявляється некоректність поведінки.
Як один із варіантів, можна вказати, що «Секція «Продукти» обрізається на сторінці межами екрану/вікна браузера».
Усе буде залежати від ситуації, в якій відтворюється баг.
Знову ж таки, як було вказано вище, є допустимі варіанти, коли використання некоректних слів займає багато місця тому їх краще винести в розширений опис бага. У такому випадку можна використовувати «некоректні слова» там.
Але в інших ситуаціях варто детально описати проблему.
Ось ще один приклад «неправильного» опису бага:
«Зміст сторінки написано неправильно».
У чому саме проявляється «неправильність» даного бага? З теми абсолютно незрозуміло, в чому полягає проблема. Чи то речення виходить за межі блоку, чи то воно обрізане або написане у неправильному форматі, чи то містить граматичні або лексичні помилки.
Баг – не головоломка, яку повинен вирішувати замовник. Хороший приклад звіту – коли замовнику навіть не потрібно дивитися скріншот або відео для розуміння проблеми.
Підводячи підсумки, необхідно розуміти, що якість оформленого баг-репорта відображає професійний рівень тестувальника. Те, наскільки грамотно буде оформлений звіт безпосередньо вплине на кінцевий результат на проєкті. Важливо розрізняти ситуації, в яких використання «некоректних» слів допустиме, а в яких – ні. Кращий спосіб – подивитися на заведений баг з боку людини, яка буде його читати і намагатися відтворити. Не потрібно забувати, що знаходження бага – це тільки частина виконаної роботи. Правильність його оформлення не менш важлива.
