Як написати звіт про помилку з прикладами
Лукас Беннетт
Що таке звіт про помилку? Навіщо потрібен хороший звіт про помилку?
Звіт про помилку — це важливий документ у STLC, який надає різноманітні переваги команді тестування. Він відстежує всі дефекти, численні помилки, помилки та інші невідповідності, виявлені під час тестування програмного забезпечення, і повідомляє про них.
Метою цієї документації після тестування є надання інформації відповідній команді професіоналів про рівень помилок, виявлених під час процесу тестування.
вашу інженер з розробки програмного забезпечення можна повідомити про всі дефекти та проблеми, наявні в програмному забезпеченні, використовуючи цей тип звіту. Це також дає вам змогу з’ясувати, що не так з помилкою, щоб ви могли використати найкращий спосіб її виправлення. Це також допоможе вам заощадити ваш час і гроші, допомагаючи виловлювати помилки та проблеми.
Чому ви маєте дбати про хороші пояснення помилок?
Ось те, що вам потрібно врахувати, щоб написати хороший детальний звіт про помилку програмного забезпечення:
- Він діє як посібник, який допоможе уникнути такої самої помилки в майбутніх випусках.
- Економія часу на спілкування (електронні листи, дзвінки).
- Less робота для розробників (вони зроблять саме те, що ви хочете).
- У вас буде менше вузьких місць у проекті; помилки будуть виправлені швидше та ефективніше.
Як написати звіт про помилку (шаблон звіту про помилку)
Немає точного шаблону звіту про помилку, оскільки це залежить від вашої системи відстеження помилок. Ваш шаблон може бути іншим.
Однак, якщо ви хочете написати звіт про помилку, завжди потрібні наступні загальні поля:
- Ідентифікатор помилки/Назва.
- Суворість і пріоритет.
- Опис
- Навколишнє середовище
- Кроки для розмноження.
- Очікуваний результат.
- Реальний результат.
- Додатки (скріншоти, відео, текст)
Давайте по черзі розглянемо всі ці компоненти усунення помилок:
1) Назва/ідентифікатор помилки:
Кожній помилці слід надати унікальний ідентифікаційний номер. Інструменти звітування про помилки мають мати унікальні номери для нових помилок, щоб ми могли легко ідентифікувати помилку.
Приклади:
❌ Погано: «Я не бачу продукт, коли я знову, tyrp його не видно».
- Нечіткі
- Агресивний
- Занадто багатослівний
просить запровадити рішення.
✅ Добре: «КОШИК – нові товари, додані до кошика, які не з’являються».
- Цей тип назви миттєво визначає проблему (CART)
- Він зосереджений на фактичній технічній проблемі.
2) Серйозність помилки:
Серйозність помилки є дуже важливим фактором у звіті про помилку. Він описує вплив дефекту на продуктивність програми.
- Блокувальник: Ця помилка призводить до збою програми.
- Основний: Критична помилка вказує на серйозні зміни в бізнес-логіці.
- Незначні: Проблема, яка не впливає на функціональність програми, але впливає на очікувані результати.
- Тривіально: Це не впливає на функціональність або роботу програми. Це може бути друкарська помилка.
3) Пріоритет помилок:
Нижче наведено загальну градацію для визначення пріоритету помилок:
- Висока: Він охоплює все, що впливає на потік або блокує використання програми.
- Середнє: Це негативно впливає на досвід користувача.
- Незначні: Усі інші помилки, наприклад (опечатки, відсутні значки, проблеми з макетом тощо).
4) Середовище:
Помилка може з'являтися в певному середовищі, а не в інших. Наприклад, іноді під час роботи веб-сайту з’являється помилка Firefox, або несправність програми лише під час роботи на Android пристрій і добре працює на iPhone.
Ці звіти про помилки можна ідентифікувати лише за допомогою кросбраузерного тестування або тестування на різних пристроях. Таким чином, повідомляючи про помилку, QA повинні мати можливість вказати, чи потрібно спостерігати помилку в одному чи кількох конкретних середовищах.
5) Резюме:
Однак додавання лише назви у звіт про помилку не відповідає меті. Отже, якщо вашої назви недостатньо, ви можете додати короткий підсумок звіту.
Ваше резюме якомога меншою кількістю слів, включаючи час і те, як виникла помилка. Ваш заголовок і опис помилки також слід використовувати під час пошуку, тому ви повинні переконатися, що ви охопили важливі ключові слова.
прикладів:
- Погано: «Я намагався додати щось до тесту, але нічого не з’явилося, коли я це зробив або натиснув кнопку».
- Добре: «Коли я намагався додати [ТОВАР] у кошик для покупок, але нічого не відбулося, коли я натиснув кнопку «додати» на веб-сторінці з оглядом конкретного продукту».
6) Етапи відтворення:
Повідомляючи про помилку, важливо вказати кроки для її відтворення. Ви також повинні вказати дії, які можуть спричинити помилку. Тут не робіть жодних загальних заяв.
Конкретизуйте кроки, які слід виконати:
Ось приклад добре написаної процедури:
Кроки:
- Виберіть продукт X1.
- Натисніть Додати в кошик.
- Натисніть «Видалити», щоб видалити товар із кошика.
7) Очікуваний результат:
У звітах про помилки важливий опис очікуваного результату для технічного завдання, дизайну результатів тестування або згідно з думкою тестувальника. Все це допомагає розробникам зосередитися на швидкому пошуку необхідної інформації.
Наприклад:
Обов’язкові поля мають бути виділені червоним кольором після натискання кнопки «Надіслати».
8) Фактичний результат:
Як випливає з назви, це поле s описує фактичний вплив помилки. Дуже важливо написати чіткий опис фактичного результату.
Наприклад:
Обов’язкові поля підсвічуються зеленим кольором після натискання кнопки «Надіслати».
9) Додатки (скріншоти та відео):
У звітах про помилки найкраще додавати файли до звітів про помилки, що полегшує сприйняття інформації, коли її потрібно відобразити візуально:
Наприклад:
- Скріншот: Скріншоти можуть легко розкрити помилки в програмі; зручно, коли помилку виділено конкретною анотацією, колом або зображенням стрілки).
- Відео: Іноді помилку важко описати словами, тому краще створити відео, щоб розробник міг виправити недолік у програмі).
10) Уражена версія:
Це уражена версія програмного забезпечення, у якій повідомляється про помилку.
11) Версія виправлення:
Це версія програмного забезпечення, у якій виправлено помилку. Отже, коли QA, який повідомив про помилку, перевіряє, чи її виправлено, він використовує правильну версію програмного забезпечення.
12) Target версія:
Цільова версія, у якій потрібно виправити помилку. Отже, коли команда розробників працює над виправленням помилки, вони здебільшого націлені на конкретну версію програми.
13) Дата закриття:
Це дата, коли помилка була закрита командою тестування програмного забезпечення. Усунення помилок є важливою та невід’ємною частиною тестування програмного забезпечення.
14) Статус:
Коли створюється нова помилка, її статус має бути відкритим. Після цього він проходить такі етапи, як «Виконується», «Виправлено», «Запускається», «Повторне відкриття» тощо.
Поради щодо написання звіту про помилку
Ось кілька важливих порад, які слід пам’ятати під час написання ефективного звіту про помилку:
- Будьте конкретними під час створення звітів про помилки. Переконайтеся, що ви не включаєте жодних непотрібних або нерелевантних фактів.
- Ви повинні негайно повідомити про помилку, як тільки її буде виявлено.
- Детально підготуйте звіт, щоб розробник міг використовувати факти та інформацію для усунення проблеми.
- Ви повинні перевірити цю саму помилку на інших подібних модулях для перевірки.
- Revтобто перегляньте звіт про помилку принаймні один раз, перш ніж надсилати його.
- Ви повинні переконатися, що звіт про помилку містить опис лише однієї помилки.
- Нарешті, ви не повинні боятися просити менеджера проекту про допомогу, якщо вам щось незрозуміло.
Інструменти звітування про помилки
Процес звітування про помилки, який виконується вручну, зараз виконується за допомогою різних інструментів звітування про помилки, доступних на ринку.
- ДЖИРА
- Відстеження помилок Zoho
- Bugzilla
Ви можете переглянути наш детальний огляд найкращий інструмент звітування про помилки.
Поширена проблема та рішення під час написання звіту про помилку:
Ось деякі поширені проблеми та їх вирішення під час написання звіту про помилку:
| Приклад повідомлення про помилку | Проблема |
|---|---|
| При множенні 2 на 3 відповідь буде позитивною. | Повідомте шаблон, а не приклад. |
| Щоб уникнути цього, під час додавання нового елемента список буде впорядковано в алфавітному порядку. | Не просто описуйте те, що не так |
| Наприклад: Для цього вам потрібно буде відкрити браузер і ввести URL-адресу сайту. Ви знайдете перше поле, "ім'я користувача", написане з помилкою. |
Завжди прямо до суті (Ніколи не розповідайте історію!). |
| Ім'я клієнта в звіті написане з помилкою. Пріоритет: високий, серйозність: високий | Ніколи не змішуйте пріоритет і суворість. |
| Формула розрахунку податку НЕПРАВИЛЬНА !!?? | Не використовує ВЕРХНІ літери, червоні літери, червоні кола, «!», |
| Я не думаю, що дизайн домашньої сторінки Ul є хорошим. | Не користуйтеся своїм судженням. |
| Приклад нечіткого опису: щодо нашого сьогоднішнього обговорення, виконайте необхідні дії для цієї сторінки. | Зробіть свій опис зрозумілим для всіх. |
| Фон сторінки повинен бути синім, помаранчевим або зеленим, або ви можете зробити його чорним або білим.
Це недобре, оскільки незрозуміло, що потрібно від команди веб-розробників і дизайну |
Мінімізуйте варіанти |
| Формула розрахунку податку іноді не працює належним чином. | Золоте правило: не використовуйте слово «іноді». |
Приклад звіту про помилку
Ось невеликий приклад звіту про помилку:
[МІЙ ОБЛІКОВИЙ ЗАПИС] Підкреслення відображається, якщо навести курсор миші на кнопку Оновити.
Descriptіон: Нам потрібно видалити підкреслення під час наведення курсора миші на кнопку «Оновити» в розділі «Мій обліковий запис».
посилання: http://test.com/mv-account/
Браузер/ОС: Chrome 25. OSX Yosemite 10.10.2
Кроки для відтворення:
1. Перейдіть на сайт www.test.com
2. Увійдіть за допомогою облікових даних
3. Перейдіть до облікового запису
4. Наведіть курсор миші на кнопку Оновити
Фактичний результат: є підкреслення.
Очікуваний результат: без підкреслення.
Дані для входу: test@test.com / mysecretpass12
Необхідно уникати помилок у написанні звіту про помилку
Ось кілька важливих помилок, яких слід уникати під час написання звіту про помилку:
- Не пишіть про своє невдоволення і ніколи не вказуйте на особисті почуття.
- Це дратує людей, які хочуть зосередитися на завданні, коли ви перевантажуєте свій пост багатьма смайликами.
- Ніколи не перевантажуйте свій пост знаками оклику; це не прискорює роботу.
- Ніхто не хоче відчувати себе скривдженим. Це руйнує мотивацію і уповільнює усвідомлення проблеми.