АТРИБУТЫ ОТЧЕТА О ДЕФЕКТЕ: ЧАСТЬ 1
🦔 сохраняем к себе, это очень и очень важно! От того, насколько вы правильно составите баг репорт, зависит скорость и качество исправления дефекта, а также ваша личная репутация как тестировщика.
💡В зависимости от инструментального средства управления отчётами о дефектах внешний вид их записи может немного отличаться, могут быть добавлены или убраны отдельные поля, но концепция остаётся неизменной!
⚠️ #Идентификатор (identifie, id)
представляет собой уникальное значение, позволяющее однозначно отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках.
⚠️ #Заголовок (summary, title)
должен быть в предельно лаконичной форме и отвечать на вопросы «Что произошло?» ,«Где это произошло?», «При каких условиях это произошло?». Например: «Отсутствует логотип на странице приветствия, если пользователь является администратором». Что произошло? Отсутствует логотип. Где это произошло? На странице приветствия. При каких условиях это произошло? Если пользователь является администратором.
⚠️ #Предусловия (preconditions)
Условия окружения и состояния, которые должны быть выполнены перед началом выполнения определенного теста или процедуры тестирования
⚠️ #Подробное описание (description)
представляет в развёрнутом виде необходимую информацию о дефекте, а также (обязательно!) описание фактического результата, ожидаемого результата и ссылку на требование (если это возможно).
Раздел включает в себя:
⚠️ #Шаги по воспроизведению (steps to reproduce, reprosteps, STR)
описывают действия, которые необходимо выполнить для воспроизведения дефекта. Это поле похоже на шаги тест-кейса, за исключением одного важного отличия: здесь действия прописываются максимально подробно, с указанием конкретных вводимых значений и самых мелких деталей, т.к. отсутствие этой информации в сложных случаях может привести к невозможности воспроизведения дефекта.
⚠️ #Фактический результат (actual result)
результат, полученный после прохождения шагов к воспроизведению.
⚠️ #Ожидаемый результат (expected result)
описывает ожидаемое поведение ПО после прохождения шагов к воспроизведению.
⚠️ #Приложения (attachments)
представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (записи экрана, логи и т.д.)
⚠️ #Relatedwork
ссылки (при их наличии) на связанные задачи/требования
#QAглазамиДжуна_полезное #тестоваядокументация #QAглазамиДжуна_понятия #багрепорт #отчетодефекте
🦔 сохраняем к себе, это очень и очень важно! От того, насколько вы правильно составите баг репорт, зависит скорость и качество исправления дефекта, а также ваша личная репутация как тестировщика.
💡В зависимости от инструментального средства управления отчётами о дефектах внешний вид их записи может немного отличаться, могут быть добавлены или убраны отдельные поля, но концепция остаётся неизменной!
⚠️ #Идентификатор (identifie, id)
представляет собой уникальное значение, позволяющее однозначно отличить один отчёт о дефекте от другого и используемое во всевозможных ссылках.
⚠️ #Заголовок (summary, title)
должен быть в предельно лаконичной форме и отвечать на вопросы «Что произошло?» ,«Где это произошло?», «При каких условиях это произошло?». Например: «Отсутствует логотип на странице приветствия, если пользователь является администратором». Что произошло? Отсутствует логотип. Где это произошло? На странице приветствия. При каких условиях это произошло? Если пользователь является администратором.
⚠️ #Предусловия (preconditions)
Условия окружения и состояния, которые должны быть выполнены перед началом выполнения определенного теста или процедуры тестирования
⚠️ #Подробное описание (description)
представляет в развёрнутом виде необходимую информацию о дефекте, а также (обязательно!) описание фактического результата, ожидаемого результата и ссылку на требование (если это возможно).
Раздел включает в себя:
⚠️ #Шаги по воспроизведению (steps to reproduce, reprosteps, STR)
описывают действия, которые необходимо выполнить для воспроизведения дефекта. Это поле похоже на шаги тест-кейса, за исключением одного важного отличия: здесь действия прописываются максимально подробно, с указанием конкретных вводимых значений и самых мелких деталей, т.к. отсутствие этой информации в сложных случаях может привести к невозможности воспроизведения дефекта.
⚠️ #Фактический результат (actual result)
результат, полученный после прохождения шагов к воспроизведению.
⚠️ #Ожидаемый результат (expected result)
описывает ожидаемое поведение ПО после прохождения шагов к воспроизведению.
⚠️ #Приложения (attachments)
представляет собой не столько поле, сколько список прикреплённых к отчёту о дефекте приложений (записи экрана, логи и т.д.)
⚠️ #Relatedwork
ссылки (при их наличии) на связанные задачи/требования
#QAглазамиДжуна_полезное #тестоваядокументация #QAглазамиДжуна_понятия #багрепорт #отчетодефекте