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

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

Кожен може написати звіт про помилку, але не кожен може написати хороший звіт про помилку. Ми розглянемо деякі особливості та методи його написання:

1. Наявність унікального номера дефекту.

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

2. Відтворюваність.

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

3. Конкретніше.

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

Як повідомити про дефект?

Це простий формат повідомлення про ваду. Він може відрізнятися залежно від інструментів, які ви використовуєте.

Репортер: Ваше ім’я та e-mail. Продукт: продукт, у якому ви виявили ваду. Версія: версія продукту, якщо доступна. Компонент: це допоміжні модулі продукту.

Платформа: Вкажіть апаратну платформу, на якій ви виявили цю помилку.

Операційна система: Перелічіть всі операційні системи, в яких ви виявили ваду. Такі операційні системи, як: Windows, Linux, Unix, SunOS, MacOS. Вказуйте різні версії операційної системи, наприклад, Windows 7, Windows 10, MacOS 10.0.1 тощо.

Пріоритет: Коли помилку має бути виправлено? Пріоритет зазвичай встановлюється від P1 до P5. P1 як “Виправити помилку з найвищим пріоритетом” і P5 як “Виправити, коли дозволить час”.

Серйозність: Описує вплив помилки. Типи тяжкість:

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

Статус: Коли ви реєструєте нову ваду у будь-якій системі, вона за замовчуванням позначається як “Нова”. Пізніше, помилка проходить різні стадії, такі як Виправлено, Перевірено, Повторно відкрито, Не буде виправлено тощо.

Призначити Кому: Якщо ви знаєте, хто з розробників відповідає за конкретний модуль, в якому виник дефект, ви можете призначити цього розробника. In other case, leave this field blank to assign a bug to the project owner or the project manager will assign a bug to the developer.

URL: URL-адреса сторінки, на якій сталася помилка.

Резюме: Короткий опис вади, здебільшого 15 слів або менше. Переконайтеся, що ваше резюме відображає: що таке помилка? де знаходиться помилка? коли виникає помилка?

Опис: Детальний опис вади. Використовуйте наступні елементи для поля опису:

• Кроки розмноження: Вкажіть чіткі кроки для відтворення помилки
• Фактичний результат: Вкажіть фактичний результат при виконанні всіх перерахованих вище кроків, тобто поведінку, що є помилковою.

• Очікуваний результат: Вказати, як повинна поводитись програма при виконанні всіх перерахованих вище кроків

Це важливі аспекти при написанні звіту про помилку. Ви також можете додати “Тип звіту” як ще одне поле, яке буде описувати тип помилки.

Типи помилок:

• Помилка кодування
• Помилка проектування
• Нова пропозиція
• Питання документації
• Апаратна проблема

І ще кілька порад щодо написання хорошого баг-репортажу:

1. Негайно повідомляйте про проблему.

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

1. Повторіть помилку тричі, перш ніж писати звіт про помилку.

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

1. Перевірте цю помилку в інших подібних модулях.

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

1. Напишіть хороший звіт про ваду.

Короткий опис помилок допоможе розробникам швидко проаналізувати природу помилок. Неякісний звіт невиправдано збільшить час розробки та тестування.

1. Прочитайте звіт про помилку, перш ніж натиснути кнопку “Відправити”.

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

1. Не використовуйте образливі фрази.

Приємно, що робота була виконана добре і баг був виявлений, але не варто використовувати цей факт для критики розробників.

Висновок:

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