Comments 7
Старайтесь ответить в названии тикета на три вопроса
ну нет, там были не совсем такие три вопроса же :) тут у вас "где происходит" и "при каких условиях" - это всё объединяется как "шаги воспроизведения"
а по классике (Джоэль Спольски и пр) по-моему так:
шаги воспроизведения
что вы увидели
что на самом деле ожидали увидеть (как должно быть)
Последний пункт нельзя забывать т.к. кому-то он может казаться очевидным в каком-то случае (нажали загрузить файл - а он не загрузился - ну ежу понятно хотели чтоб загрузился) - но в чуть более сложных кейсах уже может быть всё сложно (новый пришедший файл затирает старый - а что должно быть вместо этого? ошибка? добавление версии? ещё что-то?)
P.S. это не относится к тестированию - но для написания статьи по тестированию лучше брать какие-то забавные или гротескные примеры, про эндпойнты всё же скучно выглядит.
как опять же у классика "проблема: на мониторе пятна крови; как должно быть: без крови" и т.п.
Вы пишите разумные вещи, но видимо спорите не с тем тезисом, который привели в цитате.
Добрый день, Коллеги! Присоединюсь к данному комментарию:
Я не сторонник больших и длинных заголовков, заголовок должен быть информативным, плохая практика пытаться затащить шаги и условия. Для этого есть другие параметры баг-репорта.
Количество шагов в идеале должно стремится к 3. Лучше использовать состояния системы, описанных в пред условиях. Думаю предусловие как раз подходит к описанию того пользователя или учетной записи или роли, под которой мы должны воспроизводить дефект.
Правилом хорошего тона является указание ФР сразу после шагов, а затем ОР, т. к. мы ведем своими шагами читающего к сути самого дефекта или бага.
В некоторых случаях, полезно записывать видео с воспроизведением бага.
Баг репорт, как лучшее ТЗ, которое я видел. Было бы забавно. Но обычно хватала четких шагов воспроизведения. Есть измеримая польза от такого скрупулёзного труда?
Вводные: продуктовый QA, веб-приложение ломаем. Белый ящик, полный доступ, все дела.
Баг-репорт оставить без логов и скриншота (если затрагивается UI) в нашей команде тестирования считается лютым зашкваром. А у разработки чуть ли не за развлечение почитается достать тестера в личке, если он недостаточно информации в репорте написал.
А по разговорам в курилке понимаю, что раньше тестеры не те были и джуны уровнем пониже водились: сейчас новеньких видишь и сразу понимаешь, что от них только понимание продукта требуется, а раньше ещё культуре взаимодействия, разработки и чуть ли не тест-дизайну обучать надо было
Пишем хорошие баг репорты. Рекомендации