ШАБЛОН ОТЧЕТА ОБ ОШИБКЕ С ПОДРОБНЫМ ОБЪЯСНЕНИЕМ | МАТЕРИАЛ ДЛЯ ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Шаблон отчета о дефектах или Шаблон отчета об ошибках – это один из тестовых артефактов. Это проявляется, когда начинается этап выполнения теста.

Ранее я публиковал подробный пост «Жизненный цикл тестирования программного обеспечения (STLC)», если вы еще не прошли его, вы можете просмотреть “ Жизненный цикл тестирования программного обеспечения (STLC)» здесь

Целью использования шаблона отчета о дефектах или шаблона отчета об ошибках является передача подробной информации (например, сведений о среде, шагов для воспроизведения и т. д.) о ошибка разработчикам. Это позволяет разработчикам легко воспроизвести ошибку.

Посмотрите разницу между ошибкой, ошибкой, дефектом и сбоем здесь

Посмотрите видео ниже, чтобы увидеть «Как написать хороший отчет об ошибке с четким объяснением каждого поля»

Пожалуйста, проявите терпение. Видео загрузится через некоторое время.

Если вам понравилось это видео, подпишитесь на наш канал YouTube для получения дополнительных видеоуроков.

Шаблон отчета об ошибке — подробное объяснение

Компоненты шаблона отчета об ошибке

< p>Давайте обсудим основные поля отчета о дефекте, а в следующем посте мы узнаем, как написать хороший отчет об ошибке.

Идентификатор дефекта: добавьте дефект ID, используя соглашение об именах, за которым следует ваша команда. Идентификатор дефекта будет создан автоматически в случае использования инструмента управления дефектами.

Заголовок/Резюме: Заголовок должен быть коротким и простым. Он должен содержать конкретные термины, относящиеся к актуальной проблеме. Будьте точны при написании заголовка.

Предположим, вы обнаружили ошибку на странице регистрации при загрузке изображения профиля, которое также относится к определенному формату файла (например, файлу JPEG). Сбой системы при загрузке файла JPEG.

Примечание. Я использую этот пример в этом посте.

Хорошо: «Загрузка файла JPEG (изображения профиля) в Страница приводит к сбою системы».

Плохо: «Системный сбой».

Имя репортера: Имя того, кто обнаружил дефект ( Обычно это имя тестировщика, но иногда это может быть разработчик, бизнес-аналитик, эксперт в предметной области (SME), клиент)

Дата сообщения о дефекте: укажите дату, когда вы обнаружили ошибку.

Кто обнаружил: укажите имя того, кто обнаружил дефект. Например. QA, разработчик, бизнес-аналитик, малый и средний бизнес, клиент

Как обнаружено: в этом поле вы должны указать, как вы обнаружили, например, во время тестирования или во время проверки или во время предоставления пошагового руководства и т. д.,

Название проекта: иногда мы можем работать над несколькими проектами одновременно. Итак, правильно выбирайте название проекта. Укажите название проекта (если это продукт, укажите название продукта)

Выпуск/версия сборки: в каком выпуске возникает эта проблема. Четко укажите сведения о версии сборки.

Дефект/улучшение: если система ведет себя не так, как предполагалось, вам нужно указать это как Дефект. Если это просто запрос на новую функцию, вы должны указать ее как расширение.

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

Пример: Windows 8/Chrome 48.0.2564.103

Приоритет:Приоритет определяет, как скоро ошибка должна быть исправлена. Обычно приоритет бага устанавливается Менеджерами. Основываясь на приоритете, разработчики могли понять, как скоро она должна быть исправлена, и установить порядок устранения ошибки.

Категории приоритета:

• Высокий
• Средний
• Низкий

Подробнее о приоритете и серьезности ошибки.

< strong>Серьезность: Серьезность говорит о влиянии ошибки на бизнес клиента. Обычно степень серьезности ошибки устанавливается менеджерами. Иногда серьезность ошибки выбирают тестировщики, но в большинстве случаев ее выбирают менеджеры/руководители.

Категории серьезности:

• Блокировщик
• Критический
• Основной
• Незначительный
• Незначительный

Статус: укажите статус ошибки. Если вы только что нашли ошибку и собираетесь опубликовать ее, статус будет «Новая». В ходе исправления статус ошибки будет меняться.

(Например, новый/назначенный/открытый/исправленный/тестовый/подтвержденный/закрытый/открытый повторно/дублированный/отложенный/отклоненный/невозможно исправить/невоспроизводимый/требуется дополнительная информация)

Обязательно к прочтению : Жизненный цикл ошибки — подробное объяснение

Описание: в разделе описания вы должны кратко объяснить, что вы сделали, прежде чем столкнуться с ошибкой.

Действия по устранению ошибки. воспроизвести: В этом разделе вы должны описать, как воспроизвести ошибку шаг за шагом. Простые шаги дают разработчикам возможность исправить проблему без какого-либо хаоса. Эти шаги должны достаточно хорошо описывать ошибку и позволять разработчикам понять ошибку и принять меры, не обсуждая ее с тем, кто написал отчет об ошибке. Начните с «открытие приложения», включите «предварительные требования», если они есть, и пишите до шага, который «вызывает ошибку».

Хорошо:

< р><эм>я. Открыть URL «Ваш URL»
ii. Нажмите «Страница регистрации»
iii. Загрузить файл «JPEG» в поле фотографии профиля

Плохо:

Загрузите файл на странице регистрации.

URL: укажите URL-адрес приложения (если доступно)

Ожидаемый результат:  Каковы ожидаемые выходные данные приложения, когда вы выполняете действие, которое приводит к сбою.

Хорошо: должно отображаться сообщение «Изображение профиля успешно загружено»

Плохо: система должна принять изображение профиля.

Ранее я публиковал подробный пост «Шаблон тестового сценария с объяснением». Если вы еще не ознакомились с ним, вы можете просмотреть «Шаблон тестового сценария с пояснением» здесь.

Фактический результат. Каковы ожидаемые выходные данные приложения, когда вы выполняете действие, которое приводит к сбою.

Хорошо: “Загрузка файла JPEG (изображения профиля) в Страница регистрации приводит к сбою системы».

Плохо: система не принимает изображение профиля.

Вложения