Правила составления отчетов об ошибках

Все, что касается управления тестированием ПО...

Модератор: YuriY

Правила составления отчетов об ошибках

Сообщение YuriY » 10 фев 2008, 02:11

Аналогично теме о правилах составления тест-кейсов в этой теме я предлагаю обсудить и зафиксировать правила составления отчетов об ошибках (они же - баг-репорты).

Для начала предлагаю вот такой список правил, которые были найдены здесь: http://www.authorstream.com/presentation.aspx?pun=pawan-234-how-to-write-a-bug-report

How to Write a Bug Report. A dozen helpful tips
1. Be very specific when describing the bug. Don’t let there be any room for interpretation. More concise means less ambiguous, so less clarification will be needed later on
2. Calling windows by their correct names (by the name displayed on the title bar) will eliminate some ambiguity.
3. Don’t be repetitive. Don’t repeat yourself. Also, don’t say things twice or three times.
4. Try to limit the number of steps to recreate the problem. A bug that is written with 7 or more steps can usually become hard to read. It is usually possible to shorten that list.
5. Start describing with where the bug begins, not before. For example, you don't have to describe how to load and launch the application if the application crashes on exit.
6. Proofreading the bug report is very important. Send it through a spell checker before submitting it.
7. Make sure that all step numbers are sequenced. (No missing step numbers and no duplicates.)
8. Please make sure that you use sentences. This is a sentence. This not sentence.
9. Don’t use a condescending or negative tone in your bug reports. Don’t say things like "It's still broken", or “It is completely wrong”.
10. Don’t use vague terms like “It doesn’t work” or “not working properly”
11. If there is an error message involved, be sure to include the exact wording of the text in the bug report. If there is a GPF (General Protection Fault) be sure to include the name of the module and address of the crash.
12. Once the text of the report is entered, you don’t know whose eyes will see it. You might think that it will go to your manager and the developer and that’s it, but it could show up in other documents that you are not aware of, such as reports to senior management or clients, to the company intranet, to future test scripts or test plans. The point is that the bug report is your work product, and you should take pride in your work.
13. Hope this will help you to Write a proper Bug Report.
YuriY
Senior
 
Сообщений: 124
Зарегистрирован: 30 янв 2008, 01:18
Откуда: Kharkov

Сообщение despair » 17 мар 2008, 13:06

Напишу как я вижу описание ошибки:

1. Название ошибки: нужно писать именно суть ошибки, чтобы по названию можно было понять в чем проблема. Названия у ошибок по возможности не должны повторяться.

Далее само описание:
1. Пред условие - если это необходимо(например какие-то настройки системы или браузера).
2. Шаги ошибки. Нужно убедиться что шаги именно те, что нужно. Что ошибка действительно повторяется по записанным шагам. Попытаться оптимизировать количество шагов. В описание ошибки избегать слов "или", "возможно", "допустим" и т.д. Ошибка должна быть описано четко и без разных "но".
3. Итог ошибки - почему вы считаете что это ошибка?
4. На какой системе, браузере и т.п. это проверялось - если необходимо.
5. В какой версии продукта повторяется ошибка - если необходимо (если в БТ нет возможности привязать ошибку к определенной версии продукта)
6. Скриншот или лог - если необходим. Это довольно важное поле. Увидев скриншот или лог можно сразу понять в чем проблема. Лучше лишний раз прикрепить пусть даже ненужный скриншот или лог, чем забыть это сделать.

Фидбек: после перепроверки ошибки, если она не исправлена, или ошибка немного по другим шагам повторяется, то в комментарий необходимо вписать новые шаги (предварительно проверив их) и опять же таки, почему вы считаете это ошибкой.
best regards,
Sergey
despair
Junior
 
Сообщений: 15
Зарегистрирован: 17 мар 2008, 11:41
Откуда: Харьков

В дополнение к [b]despair[/b]

Сообщение Maria » 25 мар 2008, 17:36

В дополнение к despair
Я полностью согласна с его описанием описания ошибки :lol: , однако добавлю что "Итог ошибки" (почему считаете это ошибкой) в нашей комании мы называем "Результат" , имея в виду полученный результат после действий, описанных в шагах. А после пункта "Результат" чаще всего указываем "Ожидаемый результат", так сразу видно, что программа сработала неверно.

"На какой системе, браузере и т.п. это проверялось" - это тоже у нас обязательое поле.
"Версия продукта" указывается обязательно, это тот номер версии КОГДА обнаружилась ошибка
Еще, мы обязательно указываем важность ошибки и повторяемость.

Если подытожить, правила получаются следующе:

Важность ошибки (большая малая, пожелание неудобство)
Повторяемость (всегда, часто, иногда, не удалось, не проверялось)
Версия продукта
Предусловия (браузер, платформа, ОС и т.д.)
Суть проблемы (коротко, в чем ошибка)
Шаги воспроизведения ошибки (так как указал ниже уважаемый despair)
Результат (как сработала программа )
Ожидаемый результат (как должна была сработать)
Комментарий тестера
Статус ошибки (открытая, закрытая, пофиксенная... закрытая)
Приложения (скриншоты, логи, файлы и т.д.)
Комментарий девелопера
Отметка о решении девелопера (фикс, не могу повторить, не требует действий....)
Версия продукта , в которй девелопер пофиксил ошибку
Необходимость повторного прогона данной ошибки (тест кейса) в регрессионном тестировании (да, нет, не знаю)
.


Вот, примерно так. Кстати багтрекер Мантис, почти полностью в этом плане нас удовлетворил.

Еще статьи по теме:

Как написать хороший баг-репорт. http://software-testing.ru/lib/dukalsky ... od_bug.htm

Как эффективно сообщать об ошибках
http://software-testing.ru/lib/opencont ... report.htm
Последний раз редактировалось Maria 26 мар 2008, 11:12, всего редактировалось 1 раз.
Maria
Junior
 
Сообщений: 31
Зарегистрирован: 18 мар 2008, 15:47
Откуда: Kharkov

Сообщение lesha » 26 мар 2008, 10:51

Ко всему выше сказанному хочется добавить два небольших поля:
1. User Impact (т.е. что не получает пользователь из-за этого бага, как этот баг влияет на пользователя)
2. Workaround (как можно обойти данную ошибку)

ЗЫ Работал с Мантисом и другими BTS... Но до сих пор с огромным удовольствием вспоминаю Jira :)
lesha
Junior
 
Сообщений: 31
Зарегистрирован: 30 янв 2008, 12:19


Вернуться в Управление тестированием ПО | Test Management

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3

cron