- Навіщо потрібний гарний баг-репорт?
- Які якості гарного баг-репорту у розробці програмного забезпечення?
- Характеристики та методи для повідомлення про баг
- Ефективний баг-репортинг
- Простий шаблон баг-репорту
- Важливі фічі у вашому звіті про помилки
- Додаткові поради для написання гарного баг-репорту
- Висновок
Навіщо потрібний гарний баг-репорт?
Баг репорт це звіт про помилки. І якщо його складено правильно, то шанси на швидке виправлення цих багів вищі. Таким чином, виправлення помилки залежить від того, наскільки якісно ви про неї повідомите. Складання звітів про помилки - не що інше, як навичка, і зараз ми розглянемо, як її сформувати.
"Сенс написання звіту про проблеми (баг-репорту) полягає в тому, щоб виправити ці проблеми" - Cem Kaner. Якщо тестувальник не повідомляє про помилку правильно, програміст, швидше за все, відхиляє цю помилку, заявивши, що вона невідтворювана.
Це може нашкодити робочому настрою тестувальників, зачепити їх професійну гордість, їх его.
Які якості гарного баг-репорту у розробці програмного забезпечення?
Будь-хто може скласти приклад баг репорту. Але не кожен може написати ефективний баг-репорт.
Ви повинні вміти добре розрізняти баг-репорт середньої якості та гарний баг-репорт. Як відрізнити гарний та поганий баг-репорти? Це дуже просто – застосуйте наступні характеристики та методи, щоб якісно повідомити про помилку.
Характеристики та методи включають в себе:
1) Наявність чітко визначеного номера помилки:
Завжди надавайте унікальний номер кожному повідомленню про помилку. Це, у свою чергу, допоможе вам чітко ідентифікувати запис про помилку. Якщо ви використовуєте будь-який інструмент автоматичного формування баг-репортів, цей унікальний номер буде генеруватися автоматично кожного разу, коли ви робите звіт.
Запишіть номер та короткий опис кожної помилки, про яку ви повідомили.
2) Відтворюваність:
Якщо знайдена вами помилка невідтворювана, вона ніколи не буде виправлена.
Ви повинні чітко вказати кроки для відтворення помилки. Не приймайте та не пропускайте жодного кроку відтворення. Помилку, яка описана крок за кроком, легко відтворити та виправити.
3) Будьте конкретні:
Не пишіть нарис про проблему.
Пишіть конкретно і по суті. Спробуйте описати виявлену проблему мінімальною кількістю слів та максимально ефективним способом. Не поєднуйте описи кількох багів в одному звіті, навіть якщо вони здаються схожими. Напишіть різні звіти для кожної проблеми.
Ефективний баг-репортинг
Звіти про помилки є важливим аспектом тестування програмного забезпечення. Ефективний баг-репорт добре розуміється командою розробників і дозволяє уникнути плутанини чи непорозуміння.
Гарний звіт про помилку має бути чітким і коротким, без будь-яких пропущених ключових моментів. Будь-яка відсутність ясності веде до непорозуміння та уповільнює процес розробки. Опис дефектів та складання звітів – одна з найважливіших, але часто ігнорованих областей у життєвому циклі тестування.
Правильно складений текст звіту про знайдений баг є дуже важливим для реєстрації помилки. Один із важливих моментів, які повинен мати на увазі тестер, - це не використовувати командний тон у звіті. Такий тон порушує моральний стан колективу та створює нездорові робочі відносини. Використовуйте нейтральний тон.
Не думайте, що якщо розробник припустився помилки, то ви можете використовувати грубі слова. Перш ніж повідомляти, не менш важливо перевірити, чи був баг-репорт за цією помилкою раніше, чи ні.
Дублікати помилок – це постійна проблема у циклі тестування. Перевіряйте весь список виявлених багів. Іноді розробники можуть знати про проблему і ігнорувати її в майбутньому випуску. Використовуйте спеціальні інструменти, такі як Bugzilla, який автоматично шукає дублікати помилок. Тим не менш, найкраще додатково вручну шукати дублікати помилок.
Чітко вказуйте інформацію про помилку: «Як?» і «Де?". Звіт повинен ясно показувати, як було виконано тест і де саме стався дефект. Читач звіту повинен легко відтворити помилку та знайти її.
Майте на увазі, що мета написання баг-репорту – дати розробнику можливість візуалізувати проблему. Він повинен чітко розуміти суть дефекту, прочитавши звіт про помилку. Не забудьте надати всю необхідну інформацію, яку розробник шукає.
Крім того, майте на увазі, що звіт про помилки буде збережено для майбутнього використання і він повинен бути гарно написаний та містити необхідну інформацію. Використовуйте змістовні речення та прості слова, щоб описати знайдені помилки. Не використовуйте заплутані твердження, які витрачають час читача.
Повідомляйте про кожну помилку як про окрему проблему. У разі опису кількох багів в одному звіті, ви не зможете закрити його, доки всі проблеми не будуть вирішені.
Таким чином, краще за все розбити великі проблеми на окремі баги. Це гарантує, що кожна помилка може бути оброблена окремо. Добре написаний баг-репорт допомагає розробнику відтворити помилку у своєму терміналі. Це також допомагає їм правильно діагностувати проблему.
Простий баг репорт шаблон
Це проста форма баг-репорту. Його зміст може змінюватись в залежності від використовуваного вами інструменту для створення звітів про помилки. Якщо ви пишете баг-репорт вручну, необхідно згадати деякі поля, наприклад номер помилки, який повинен бути призначений вручну.
Укладач звіту: Ваше ім'я та адреса електронної пошти.
Продукт: У якому продукті ви знайшли цю помилку.
Версія: Версія продукту з помилкою, якщо така є.
Компонент: Основні підмодулі продукту.
Платформа:
Вкажіть апаратну платформу, де ви виявили цю помилку. Різні платформи, такі як "ПК", "MAC", "HP", "Sun" і т. д.
Операційна система:
Вкажіть усі операційні системи, у яких ви виявили помилку. Операційні системи, як-от Windows, Linux, Unix, SunOS, Mac OS. Згадайте різні версії ОС, такі як Windows NT, Windows 2000, Windows XP і т. д., якщо це можна застосувати.
Пріоритет:
Коли потрібно виправляти помилку? Пріоритет зазвичай встановлюється від P1 до P5. P1 слід розуміти як "виправити помилку з найвищим пріоритетом" і P5 - "виправити, якщо дозволяє час".
Серйозність помилки:
Визначає вплив помилки.
Типи Серйозності помилки:
- Блокувальник (Blocker): подальша робота з тестування неможлива.
- Критична (Critical): збій застосунку, втрата даних.
- Major: серйозна втрата функціональності.
- Minor: незначна втрата функціональності.
- Незначна (Trivial): деякі поліпшення інтерфейсу користувача.
- Поліпшення (Enhancement): запит нової функції або деякого покращення існуючої.
Статус помилки:
Коли ви реєструєте помилку в будь-якій системі відстеження помилок, за замовчуванням статус помилки буде «Новий».
Пізніше помилка проходить через різні етапи, такі як "Виправлено", "Перевірено", "Повторно відкрито", "Не виправлено" тощо.
Призначити розробнику:
Якщо ви знаєте, який розробник відповідає за той конкретний модуль, в якому виникла помилка, ви можете вказати адресу електронної пошти цього розробника. В іншому випадку залиште це поле порожнім, оскільки це надасть полю авторства помилки значення власника модуля, якщо менеджер не призначить помилку розробнику.
URL:
URL-адреса сторінки, на якій сталася помилка.
Коротке резюме:
Додайте короткий опис помилки. Орієнтуйтесь на 60 слів або менше. Переконайтеся, що складене резюме відображає проблему та місце, де вона знаходиться.
Опис:
Детальний опис помилки.
Використовуйте такі поля для поля опису:
- Відтворювані кроки: чітко згадайте кроки для відтворення помилки.
- Очікуваний результат: як додаток має поводитися на вказаних вище етапах.
- Фактичний результат: який фактичний результат виконання вищезгаданих кроків, тобто поведінка помилки.
Відео курси за схожою тематикою:
Це важливі кроки у звіті про помилки. Ви також можете додати "Тип звіту" як ще одне поле, яке описуватиме тип помилки.
Типи звітів включають в себе:
- Помилка в коді
- Помилка проєктування
- Нова пропозиція
- Проблема із документацією
- Апаратна проблема
Важливі фічі у вашому звіті про помилки
Розглянемо кілька складових звіту про знайдений баг.
Нижче наведено важливі елементи баг-репорту:
1) Номер помилки/ідентифікатор:
Номер помилки або ідентифікаційний номер (наприклад, xyz007) значно спрощує складання баг-репорту та пошук місця помилки. Розробник може легко перевірити, чи виправлено конкретну помилку, чи ні. Це робить весь процес тестування та повторного тестування більш плавним та легким.
2) Найменування помилки:
Заголовок помилки читається частіше, ніж будь-яка інша частина баг-репорту. Варто вказати в ньому все про те, що входить в баг.
Назва помилки має бути досить осмисленою, щоб читач міг її зрозуміти. Чіткий заголовок помилки полегшує розуміння, і читач легко зможе перевірити, чи було повідомлення про помилку раніше і чи було її виправлено.
3) Пріоритет:
В залежності від серйозності помилки для неї може бути встановлений пріоритет. Помилка може бути Blocker, Critical, Major, Minor, Trivial або пропозицією щодо покращення функціоналу. Пріоритет помилки від P1 до P5 може бути заданий так, щоб найважливіші з них переглядалися першими.
4) Платформа/Середовище:
Вказівка конфігурації ОС та браузера потрібна для більшої точності в баг-репорті. Це найкращий спосіб повідомити, як можна відтворити помилку.
Без точної платформи або середовища програма може поводитися по-іншому, і помилка на стороні тестувальника може не повторюватися на стороні розробника. Тому краще чітко вказати середовище, в якому було виявлено помилку.
5) Опис:
Правильний опис помилки допомагає розробнику зрозуміти помилку. Він описує проблему, що виникла. Поганий опис створить плутанину та витратить час розробників і тестерів.
Необхідно чітко повідомити про ефект в описі. Завжди корисно використовувати повні речення. Рекомендується описувати кожну проблему окремо. Не використовуйте такі терміни, як «я думаю» чи «я вважаю».
6) Кроки для відтворення помилки:
Гарний звіт про помилку має чітко вказувати кроки для відтворення. Кроки повинні включати дії, які спричиняють помилку. Не робіть загальних заяв. Будьте конкретні у наступних кроках.
Гарний приклад правильно написаної покрокової процедури наведено нижче:
Послідовність кроків:
- Виберіть продукт wer05.
- Натисніть на «Додати до кошика».
- Натисніть «Видалити», щоб видалити продукт із кошика.
7) Очікуваний та фактичний результат:
Опис помилки буде неповним без зазначення очікуваних та фактичних результатів. Необхідно описати в загальних рисах, який результат тесту і що очікував користувач у разі коректної роботи програми. Читач звіту повинен знати, який результат тесту буде коректним. Чітко згадайте, що сталося під час тесту і який був результат.
8) Скріншот:
Одна картинка коштує тисячі слів. Зробіть скріншот із прикладом збою з відповідними виділеннями, щоб вказати дефект. Виділіть несподівані повідомлення про помилки світло-червоним кольором. Це привертає увагу до необхідної області.
Деякі додаткові поради для написання гарного баг-репорту
Нижче наведено деякі додаткові поради, щоб написати гарний звіт про помилку:
1) Негайно повідомте про проблему:
Якщо ви виявите будь-яку помилку під час тестування, не потрібно чекати, щоб написати докладний звіт про помилку пізніше. Натомість напишіть звіт про помилку негайно. Це забезпечить гарну якість звіту та відтворюваність кроків отримання помилок. Якщо ви вирішите написати звіт про помилку пізніше, то є великі шанси пропустити важливі деталі в баг-репорті.
2) Відтворіть помилку тричі перед написанням баг-репорту:
Ваш баг має бути відтворюваним. Переконайтеся, що ваші кроки досить чіткі, щоб відтворити помилку без будь-якої двозначності. Якщо ваша помилка не відтворюється щоразу, ви все одно можете помилитися, вказавши періодичну природу багу.
3) Протестуйте цю ж помилку на інших схожих модулях:
Іноді розробник використовує один і той самий код для різних схожих модулів. Таким чином, ймовірність того, що помилка в одному модулі виникне і в інших подібних модулях, вища. Ви навіть можете спробувати знайти серйознішу версію знайденої помилки.
4) Складіть гарне резюме помилки:
Короткий опис помилки допоможе розробникам швидко проаналізувати природу помилки. Низька якість звіту надмірно збільшить час розробки та тестування. Правильно взаємодійте з вашим баг-репортом. Майте на увазі, що зведення про помилки використовується як довідкова інформація для пошуку помилки в інвентарі помилок.
5) Прочитайте декілька разів звіт про помилку, перш ніж натиснути кнопку «Надіслати»:
Прочитайте всі речення, формулювання та кроки, які використовуються у баг-репорті. Подивіться, чи не створює якесь речення двозначність, яка може призвести до неправильної інтерпретації. Слід уникати слів або речень, що вводять в оману, щоб скласти чітке повідомлення про помилку.
Безкоштовні вебінари за схожою тематикою:
6) Не використовуйте образливих виразів:
Приємно, що ви зробили хорошу роботу і виявили помилку, але не використовуєте це для критики розробника чи нападок на будь-яку людину.
Висновок
Що таке баги? Це недосконалості ПЗ, з якими необхідно боротися, і один із головних помічників у цьому – репорти про помилки.
Ми розглянули деякі особливості складання звіту про знайдений баг. Немає сумнівів, що ваш баг-репорт повинен бути якісним документом.
Зосередьтеся на написанні гарних звітів про помилки і витратьте деякий час на виконання цього завдання, оскільки саме якісний баг-репорт є основною точкою зв'язку між тестером, розробником та менеджером. Менеджери зі свого боку повинні пояснити своїй команді, що складання гарного звіту про помилки є основним обов'язком будь-якого тестувальника.
Ваші зусилля щодо написання гарного звіту про помилки не тільки збережуть ресурси компанії, але й створять гарні стосунки між вами та розробниками.
Для кращої продуктивності команди намагайтеся написати якомога гарний звіт про помилки.
З нашого боку для якісної підготовки тестувальників пропонуємо вам ознайомитися з курсом підготовки спеціаліста-тестувальника на ITVDN - Quality Assurance.
За матеріалами статті.
Статті за схожою тематикою
