Как правильно составлять баг-репорты

[dimakey]

Тестер помни: багрепорт «ничего не работает!» оскорбляет чувства программирующих.

[antarx]

Багрепорт «ничего не работает!» позорит «тестера» и профессию.

[Tibr]

>>Пример плохого заголовка: «Все виснет, когда я вставляю текст из буфера обмена»

— У нас в компании это пример самого распространенного заголовка.

[slip7]

у вас так часто всё виснет когда вставляешь из буфера обмена?))

[Tibr]

С чего Вы взяли?

[Tibr]

Кэп подсказывает, что смысл комментария в том, у нас часто пишут «плохие» заголовки, а не именно такие, как в примере, на то он и пример.

[FWhisper]

У нас, кстати, часто. Почему-то большинство программистов не любят ставить ограничение на количество символов в текстовом поле…

[freiman]

Да, хорошее замечание.
Сам всегда выделяю красной рамкой место, на которое надо обратить внимание. А вот упомянуть об этом в посте забыл.

[FWhisper]

Вы серьёзно предлагаете перебирать посимвольно кусок текста тестировщику, если с этим куском падает приложение? Даже бинарным поиском тестировщик на это потратит в разы больше времени, чем программист с дебаггером, мне кажется.

Да, я понимаю, что это просто пример, но нахожу его как минимум неоднозначным.

[freiman]

Бинарным поиском подобные задачи решаются довольно быстро.

А пример, конечно, весьма условный, не из рабочей практики.

[vorobyev]

Ну это распространенное пожелание к тестировщикам. Во времена работы в Cybiko на одном из совещаний был высказан тезис, что хороший тестировщик, должен уметь находить ошибки кода, архитектуры и дизайна, качественно описывать их и предлагать работающее исправление. На что было предложено тогда уволить всех программистов и дизайнеров. Начальнику отдела — бросать тестировщикам ярлык для проверки, чтобы потом они исправлением ошибок доводили продукт до ума ;-)

[freiman]

Находить ошибки кода и архитектуры (ага, при тестировании методом черного ящика к тому же :) ) может тестировщик 90lvl, такой в лучшем случае один на всю компанию :)

[Allenary]

Можно еще упомянуть принцип «Что? Где? Когда?». В большинстве случаев это помогает написать удачный заголовок/подробное описание, Например,
Что: неправильный расчет данных
Где: на странице NNN
Когда: после ввода а поле Y отрицательного значения.

[freiman]

Да, хороший принцип.

[rmpl]

не соглашусь про видео. бывают последовательности и результаты, которые намного проще показать на видео чем описывать или скриншотить

[freiman]

а проще ли их потом воспроизвести программисту? или вам самим для проверки исправления бага?

[vorobyev]

И не забывайте о конфигурации тестового стенда!
Возможно в этом посте это подразумевалось под шагами, но обычно она указывается отдельно и может включать в себя( в зависммости от типа тестируемого ПО:
1. Версия тестируемой программы.
2. Версия окружения( система, браузер, специальные библиотеки).
3. Версия железа на котором происходит ошибка( если РС, то процессор, память, видео. Для мобильных устройств — тип мобильного устройства).

[freiman]

Да, про это немного есть в посте.
Я разделил пункт на «affect version» и «environment»
affect version — версия тестируемой программы
environment — версия окружения, железа.

[vorobyev]

Ага, теперь увидел. При первом прочтении как то проскользнуло.
Еще хорошо бы написать что делать если ошибка не воспроизводится, или воспроизводится статистически( т.е. конкретного алгоритма как ее получить — нет, но в течении некоторого времени она проявляется). Конечно это индивидуально для каждой компании, но мы такого рода ошибки собирали, потом помогало понимать что может еще рухнуть.

[urecogurec]

Вы забыли о следующем моменте: как быть, когда существует несколько путей воспроизведения ошибки?

[freiman]

Достаточно указать один, самый короткий/простой для воспроизведения.
Главное — воспроизвести ошибку, чтобы понять ее причину.

А когда вы перепроверяете, то можете попробовать все пути воспроизведения.

[vorobyev]

Опять же зависит от платформы и политики компании. Иногда бывает полезно разнести разные пути воспроизведения в разные записи. Возможно они инициированы разными проблемами в коде и исправление одной на другие не повлияет — проверять придется все.

[urixx]

а в нашем баг трекере раздел Environment ограничивается именем ОС! Из-за этого приходится постоянно задавать одни и те же вопросы :(. Вообще, очень правильная статья

[freiman]

Попросите ответственного за BTS добавить еще поле — сейчас инструмент не решает всех возложенных на него задач.

У нас Environment — это просто поле для свободного ввода, можно писать все, что нужно в рамках данной конкретной задачи.

[JuliyaErina]

Из воспоминаний профессиональной юности: Когда прислала подобное руководство девочке-тестеру, которая любит писать баг-репорты в стиле «Программа не работает», она перестала со мной общаться и перевелась в др. отдел. Добавила статью в избранное — теперь в случае возникновения подобной ситуации будут ненавидеть Вас :)

[CREA]

Систем, которые выполняют подобные функции и стоят копейки или даже бесплатно — кучи — JIRA, BaseCamp, HollyTask. Вот даже тут почитать: www.hollytask.com/ru_bugreport