Часть I здесь
Реальные описания дефектов, которые я встречал, и некоторые — делал сам 😉
«Использовав поиск я получил java script ошибку»
«Не получается скопировать на флешку логи»
«Поведение программы не соответствует здравому смыслу»
Или просто копирование заголовка.
Один из моих самых любимых примеров: «Горизонт города завален» (хорошо, что баг создавал художник для художников. Шедеврально, тем не менее)
Весьма детальные описания, не так ли?
Это ведь те самые, шаги для воспроизведения, по которым проблему, о которой мы сообщаем должны воспроизвести.
Очень легко понять, где, когда и что надо запустить, в каком порядке?
«У меня что, нет более важной работы, чем писать детальное и подробное описание?» Нет, нет, конечно же есть. Очень важная — погнать тестировать приложение дальше. А дефект? Да на пальцах можно будет объяснить программисту. Да хоть 10 дефектов. Ведь главное найти миллионы и миллиарды ошибок и… И вообще программист уточнит!
Вышенаписанное — ересь, а не руководство к действию.
А если серьезно, всё это, конечно, здорово: и драйв от нахождения ошибок и адреналин от того, что было потрачено несколько часов, найдено несколько простых действий и вуаля — приложение ломается так, что мама-не горюй. Только вот, не надо забывать, что секретарей сидящих рядом с тестировщиком, для стенограмм ошибок, как-то не замечено на просторах IT отрасли. Или есть такие счастливцы? 🙂
Пишите простые и однозначные шаги, с нумерацией.
Почему бы не написать как для робота:
- Встать в начало координат (точка 0,0)
- Сделай шаг вперёд.
- Повернись по часовой стрелке на 90°.
- Сделать шаг вперёд.
- Сделать шаг вперёд.
- Повернуться против часовой стрелки на 90°
- Повернуться против часовой стрелки на 90°
Ведь не сложно?
По этим шагам, не особо задумываясь можно воспроизвести ошибку для последующего анализа. Можно автоматизировать воспроизведение.
Резонный вопрос — зачем нумерация?
Представьте ситуацию, когда вы дефект обсуждаете по телефону, и необходимо прояснить какой-нибудь шаг.
Ситуация когда нет нумерации:
— Ну в третьем шаге — я не могу повернуть, у меня валится ошибка!
— В третьем, это в каком? Откуда счёт начинаем?
— Это тот шаг, который после шага впёред.
Весело, да?:)
Это хорошо ещё, если форматирование без нумерации не поменяли, и не сделали всё описание в одну строчку. Поверьте, такое бывает.
Часть II.2 здесь.
4 комментария
3 пинга
Перейти полю для комментария ↓
Ellesta
Май 11, 2011 в 18:27 (UTC 4) Ссылка на этот комментарий
Нумерация — это очень полезно. И в описании дефекта. И в комментах.
Мне часто приходится ретестить дефекты, и я нередко в комментах тоже пишу по степам с нумерацией, что я делала. Или какие случаи протестировала. Удобнее для восприятия.
Сергей Атрощенков
Май 11, 2011 в 21:30 (UTC 4) Ссылка на этот комментарий
А случаи, которые тестируются дополнительно — нумеруются? 🙂
Ellesta
Май 11, 2011 в 22:17 (UTC 4) Ссылка на этот комментарий
Не совсем поняла вопрос.
Попробую на примере. Я тестирую финансовое приложение. В описании сказано, что был создан ордер и там-то появилась такая-то ошибка. Дефект в статусе Fixed, мне нужно проретестить и убедиться. Но есть несколько типов ордеров. Я проверяю один такого же типа как в дефекте и еще 3 дополнительно. Соответственно, получаю пункты 1, 2, 3, 4 с результатами ретеста 🙂
Сергей Атрощенков
Май 11, 2011 в 22:48 (UTC 4) Ссылка на этот комментарий
Понял, спасибо 🙂
Мысли о баг-репортах. Часть I. «Title» он же «Заголовок» | BarbaricQA.com
Май 11, 2011 в 12:57 (UTC 4) Ссылка на этот комментарий
[…] II.1 здесь Tweet Поделиться Запись опубликована в рубрике […]
Мысли о баг-репортах. Часть II.2. «Description» оно же «Описание» | BarbaricQA.com
Май 13, 2011 в 19:15 (UTC 4) Ссылка на этот комментарий
[…] Часть II.1 здесь […]
Итоговое руководство по составлению отчетов об ошибках. | BarbaricQA.com
Декабрь 12, 2011 в 01:01 (UTC 4) Ссылка на этот комментарий
[…] Мысли о баг-репортах. Часть II.1. «Description» оно же «Описани… […]