Баг репорт - це технічний документ і в зв'язку з цим хочемо відзначити, що мова опису проблеми повинен бути технічним. Повинна використовуватися правильна термінологія при використанні назв елементів призначеного для користувача інтерфейсу (editbox, listbox, combobox, link, text area, button, menu, popup menu, title bar, system tray і т.д.), дій користувача (click link, press the button , select menu item і т.д.) і отриманих результатах (window is opened, error message is displayed, system crashed і т.д.).
Вимоги до обов'язкових полях баг репорт
Відзначимо, що обов'язковими полями баг репорт є: короткий опис (Bug Summary), серйозність (Severity), кроки до відтворення (Steps to reproduce), результат (Actual Result), очікуваний результат (Expected Result). Нижче наведені вимоги і приклади щодо заповнення цих полів.
Короткий опис
Назва говорить сама за себе. В одному пропозиція вам треба вмістити сенс всього баг репорт, а саме: коротко і ясно, використовуючи правильну термінологію сказати що і де не працює. наприклад:
- Додаток зависає, при спробі збереження текстового файлу розміром більше 50 Мб.
- Дані на формі "Профайл" не зберігаються після натискання кнопки "Зберегти".
На додаток пропонуємо вам вивчити Принцип "Де? Що? Коли?". описаний на сторінках блогу "QA Nest":
"У чому цей принцип полягає?
Складіть речення, в якому факти дефекту викладені в наступній послідовності:
серйозність
У двох словах можна відзначити, що якщо проблема знайдена в ключовий функціональності програми і після її виникнення додаток стає повністю недоступно, і подальша робота з ним неможлива, то вона блокує. Зазвичай все блокують проблеми знаходяться під час первинної перевірки нової версії продукту (Build Verification Test. Smoke Test), тому що їх наявність не дозволяє повноцінно проводити тестування. Якщо ж тестування може бути продовжено, то серйозність даного дефекту буде критична. На рахунок значних. незначних і тривіальних помилок питання досить прозорий і на наш погляд не вимагає зайвих пояснень.
Кроки до відтворення / Результат / Очікуваний результат
Дуже важливо чітко описати всі кроки, з згадуємо всіх даних, що вводяться (імені користувача, даних для заповнення форми) і проміжних результатів.
Основні помилки при написанні багів репортів
Недостатність наданих даних
Не завжди одна і таж проблема проявляється при всіх впроваджуються значеннях і під будь-яким увійшов в систему користувачем, тому настійно рекомендується вносити всі необхідні дані в баг репорт
визначення серйозності
Дуже часто відбувається або завищення, або заниження серйозності дефекту, що може привести до неправильної черговості при вирішенні проблеми.
Мова опису
Часто при описі проблеми використовуються неправильна термінологія або складні мовні звороти, які можуть ввести в оману людину, відповідальну за вирішення проблеми.
Відсутність очікуваного результату
У випадках, якщо ви не вказали, що ж має бути необхідним поведінкою системи, ви витрачаєте час розробника, на пошук цієї інформації, тим самим уповільнює виправлення дефекту. Ви повинні вказати пункт у вимогах, написаний тест кейс або ж ваша особиста думка, якщо ця ситуація не була документована.
Заповнення полів баг репорт
В описаній нижче таблиці представлені основні поля баг репорт і роль працівника, відповідального за заповнення даного поля. Червоним кольором виділені обов'язкові для заповнення поля:
Відповідальний за заповнення поля