В прошлой статье мы с вами начали разбирать Атрибуты отчёта о дефектах. Разобрали Заголовок, Описание и шаги воспроизведения. Сегодня продолжим разбирать оставшиеся атрибуты.
Фактический и ожидаемый результат
Фактический результат в отчёте о дефекте (баг-репорте) – это описание того, что произошло в результате выполнения определённых действий в системе или приложении. Он включает в себя информацию о том, что пользователь ожидал увидеть после выполнения определённых шагов, и что он увидел на самом деле.
Фактический результат обычно описывается в разделе “Ожидаемый результат” и “Фактический результат” баг-репорта. В разделе “Ожидаемый результат” тестировщик указывает, что должно произойти согласно требованиям или ожиданиям пользователя. В разделе “Фактический результат” описывается, что произошло на самом деле после выполнения указанных действий.
Например, если пользователь пытается войти в систему, он ожидает увидеть приветственное сообщение после успешного входа. Однако, если вместо этого он видит ошибку авторизации, это будет фактическим результатом, который отличается от ожидаемого.
Важно, чтобы фактический результат был максимально точным и подробным, чтобы разработчики могли быстро и эффективно исправить дефект.
Пример фактического результата:
После ввода данных в форму регистрации и нажатия кнопки «Зарегистрироваться», пользователь перенаправляется на главную страницу сайта без отображения сообщения о успешной регистрации.
Пример ожидаемого результата:
После ввода данных в форму регистрации и нажатия кнопки «Зарегистрироваться», пользователь должен быть перенаправлен на страницу благодарности за регистрацию с сообщением о том, что регистрация прошла успешно.
Также важно акцентировать внимание на разнице между этими результатами, чтобы можно было понять, чего не хватает.
Серьёзность
Серьезность (Severity) в отчете о дефекте указывает на влияние обнаруженной ошибки на функциональность приложения. Это помогает определить приоритет исправления дефекта. Существует несколько уровней серьезности:
- Блокирующая (Blocker) - ошибка, которая делает приложение полностью неработоспособным. Например, если приложение “падает” при попытке найти свободное такси, это будет блокирующая ошибка, поскольку дальнейшее использование приложения невозможно.
- Критическая (Critical) - ошибка, которая нарушает основную функциональность приложения, делая его частично неработоспособным. Например, если приложение не позволяет пользователю завершить процесс оплаты, это будет критическая ошибка.
- Значительная (Major) - ошибка, которая существенно влияет на функциональность приложения, но не делает его полностью неработоспособным. Например, если приложение отображает неправильные данные в важном отчете, это будет значительная ошибка.
- Незначительная (Minor) - ошибка, которая не оказывает существенного влияния на функциональность приложения, но может вызывать неудобства для пользователя. Например, если в приложении есть опечатка в слове, это будет незначительная ошибка.
- Тривиальная (Trivial) - ошибка, которая не влияет на функциональность приложения и может быть легко исправлена. Например, если в приложении есть ошибка форматирования, которая не влияет на работу функционала, это будет тривиальная ошибка.
Определение серьезности ошибки помогает расставить приоритеты в исправлении дефектов, начиная с наиболее критических и заканчивая незначительными.
Часто путаю понятия Серьёзность и Приоритет. Давайте разберём между ними отличия.
Серьёзность в отчёте о дефекте указывает на влияние обнаруженной ошибки на функциональность приложения. Она помогает определить, насколько критично исправление дефекта.
Приоритет, в свою очередь, определяет очерёдность исправления дефекта. Он указывает, когда необходимо исправить ошибку.
Разница между серьёзностью и приоритетом заключается в том, что серьёзность оценивает влияние ошибки на приложение, а приоритет определяет порядок исправления ошибок.
Например, если в приложении обнаружена ошибка, которая делает одну из его частей полностью неработоспособным, то такая ошибка будет иметь серьёзность «блокирующая», но этот функционал очень редко используется, так что можно поставить "низкий" приоритет. Это означает, что её необходимо исправить, но если есть более важные задачи, то можно отложить.
Однако, если в приложении есть ошибка, которая не влияет на его работоспособность, но вызывает недовольство пользователей, то такая ошибка может иметь серьёзность «незначительная», но приоритет «высокий», поскольку её исправление повысит удовлетворённость пользователей.
Приоритет
Приоритет в отчёте о дефекте указывает на очерёдность исправления дефекта. Он определяется на основе оценки влияния дефекта на функциональность приложения и бизнес-процессы.
Существует три уровня приоритета:
- Высокий (High) — дефекты с таким приоритетом требуют немедленного исправления, так как они оказывают значительное влияние на работу приложения или бизнеса.
- Средний (Medium) — дефекты со средним приоритетом также важны, но их исправление может быть отложено на некоторое время, если есть более срочные задачи.
- Низкий (Low) — дефекты с низким приоритетом могут быть исправлены в будущем, когда появятся свободные ресурсы.
Определение приоритета помогает разработчикам и тестировщикам сосредоточиться на наиболее важных задачах и эффективно использовать свои ресурсы.
Статус
Статус в отчёте о дефекте отражает текущее состояние процесса исправления ошибки. Он меняется по мере прохождения дефекта через различные этапы жизненного цикла.
Основные статусы:
- Открыт (Open) — дефект обнаружен и добавлен в систему отслеживания ошибок.
- В работе (In Progress) — разработчик начал работу над исправлением дефекта.
- Исправлен (Fixed) — дефект успешно исправлен, и исправление проверено.
- Закрыт (Closed) — дефект больше не требует внимания, так как исправление было проверено и признано успешным.
Также могут использоваться дополнительные статусы, например:
- Отложен (Deferred) — исправление дефекта решено отложить на более поздний срок.
- Повторно открыт (Reopened) — дефект был закрыт, но затем снова обнаружен
Тестовое окружение
Тестовое окружение в отчёте о дефекте включает в себя всю среду, в которой проводится тестирование программного обеспечения. Оно описывает конфигурацию оборудования, программного обеспечения и сетевых настроек, необходимых для воспроизведения проблемы.
Описание тестового окружения важно для нескольких причин:
- Воспроизводимость: Позволяет другим специалистам точно воспроизвести проблему, используя те же настройки и условия.
- Понимание контекста: Даёт контекст, необходимый для понимания того, как и где возникла проблема.
- Эффективность исправления: Помогает разработчикам определить, какие изменения необходимы для устранения проблемы, учитывая специфику окружения.
Пример описания тестового окружения:
Операционная система: Windows 10
Браузер: Google Chrome 114
Разрешение экрана: 1920x1080
Это лишь базовый пример, и в зависимости от специфики проекта, описание может включать множество других деталей, таких как версии библиотек, фреймворков, баз данных и т.д.
Важность описания тестового окружения:
- Точность: Позволяет точно определить, какие компоненты системы задействованы в проблеме.
- Эффективность: Ускоряет процесс диагностики и исправления проблем.
- Документация: Создаёт полную картину ситуации, которая может быть полезна для будущих проектов и обновлений.
Вложения
Вложения в отчёте о дефекте представляют собой файлы, которые помогают наглядно продемонстрировать проблему и облегчить её понимание и устранение. Они могут быть любыми файлами, которые имеют отношение к дефекту, например:
- Скриншоты: изображения, показывающие проблему на экране.
- Видеозаписи: записи экрана, демонстрирующие проблему в действии.
- Логи файлов: текстовые файлы, содержащие информацию о событиях в системе, которые могут помочь в диагностике проблемы.
- Конфигурационные файлы: файлы настроек программы, которые могут быть важны для воспроизведения проблемы.
- Файлы данных: файлы, содержащие данные, которые используются программой и могут быть причиной проблемы.
Вложения должны быть связаны с дефектом и помогать в его понимании и устранении. Они должны быть добавлены в отчёт о дефекте для того, чтобы разработчики могли быстро и эффективно решить проблему.
Как правильно составить отчёт о дефекте
При составлении отчёта о дефекте важно соблюдать несколько основных правил:
- Следуйте правилу «Что? Где? Когда?». В отчёте должна быть чётко описана проблема, место, где она возникла, и обстоятельства, при которых это произошло.
- Составляйте отчёт сразу после обнаружения дефекта, не откладывайте это на потом. Чем быстрее вы сообщите о проблеме, тем быстрее она будет решена.
- Описывайте только одну ошибку в одном отчёте. Не объединяйте несколько проблем в одном документе.
- Прикрепляйте дополнительные файлы, такие как логи, скриншоты и видео. Это поможет разработчикам лучше понять проблему.
- Будьте лаконичны. Избегайте излишней детализации и длинных описаний.
- Часть логов можно прикрепить непосредственно в описании. Это облегчит поиск дефектов по сообщениям об ошибках, выдаваемым приложением.
- Перед составлением отчёта убедитесь, что вы можете воспроизвести дефект. Это поможет вам точнее описать проблему и предоставить больше информации разработчикам.
- Минимизируйте количество шагов в описании. Избегайте подробных инструкций, которые могут запутать разработчиков.
- Используйте технический язык и терминологию, принятую на вашем проекте. Это поможет избежать недопонимания.
- Используйте видео, чтобы кратко описать дефект и избежать недопонимания.
- Прикрепляйте ссылки к требованиям, чтобы избежать споров и сэкономить время.
- Проверяйте, нет ли дубликатов дефектов, прежде чем составлять отчёт.
- Укажите версию ПО и тестовый стенд (окружение), на котором был обнаружен дефект.
- Воспроизведите дефект, следуя вашим собственным шагам. Это поможет разработчикам быстрее разобраться в проблеме.
При составлении отчёта о дефекте важно избегать следующих ошибок
- Неполное описание проблемы. Убедитесь, что вы предоставили достаточно информации о дефекте, чтобы разработчики могли его воспроизвести и исправить.
- Отсутствие контекста. Опишите, при каких условиях возник дефект, чтобы разработчики могли понять, как его воспроизвести.
- Использование непонятных терминов. Используйте термины, которые понятны разработчикам. Если вы используете специализированные термины, объясните их значение.
- Слишком много деталей. Избегайте излишней детализации. Предоставьте только ту информацию, которая необходима для воспроизведения и исправления дефекта.
- Отсутствие скриншотов или видео. Если возможно, предоставьте скриншоты или видео, которые демонстрируют дефект. Это поможет разработчикам лучше понять проблему.
- Дублирование дефектов. Перед составлением отчёта проверьте, нет ли уже зарегистрированного дефекта с аналогичными симптомами.
- Неправильное указание версии ПО или тестового стенда. Убедитесь, что вы указали правильную версию ПО и тестовое окружение, на котором был обнаружен дефект.
- Невоспроизводимость дефекта. Прежде чем составлять отчёт, убедитесь, что вы можете воспроизвести дефект.
- Отсутствие ссылок на требования. Если дефект связан с определёнными требованиями, укажите на них ссылку.
- Неактуальная информация. Регулярно обновляйте информацию о дефектах, чтобы она оставалась актуальной.
Пример отчёта о дефекте
Заголовок: Проблема с отображением товара
Описание: При просмотре карточки товара не отображается его изображение. Отсутствие изображения товара может негативно сказаться на конверсии, так как покупатели не смогут оценить внешний вид товара.
Шаги воспроизведения:
- Перейдите на страницу товара.
- Нажмите на карточку товара.
- Обратите внимание, что изображение товара не отображается.
Фактический результат: Изображение товара не отображается.
Ожидаемый результат: Изображение товара должно отображаться.
Серьёзность дефекта: Значительная (Major)
Приоритет: Высокий (High)
Статус: Открыт
Тестовое окружение:
- Версия ПО: 1.0.0
- Тестовое окружение: Windows 10, Chrome 80
- Скриншот: прилагается
Вложение: (фото/видео)
Если у вас есть вопросы или вы просто хотите стать частью команды тестировщиков, то переходи в ТГ канал, где можем пообщаться с единомышленниками и найти много интересных и полезных знаний!Также если вам нужна индивидуальная консультация, менторство и помощь в создании проекта пишите в ТГ канал!