Баг-репорты — Рабочий процесс тестировщика

• Основные поля баг-репорта
• Уровень дефектов

Баг-репорты – отчеты об ошибках или дефектах. Тестировщик составляет баг-репорт по итогам нахождения дефекта.

Зачем их составлять?

1. Чтобы передать информацию разработчикам, которые исправят дефект
2. Чтобы сохранить информацию о дефекте и потом проверить, исправлен ли дефект
3. Чтобы составлять различные метрики

Основные поля баг-репорта

• ID — уникальный идентификатор бага
• Заголовок / Краткое описание / Тема / Summary / Title — четко и кратко описывает суть бага
• Шаги к воспроизведению — четкое, последовательное описание шагов / действий, которые необходимо совершить, чтоб воспроизвести баг со всей необходимой информацией
• Фактический результат — результат, который мы видим
• Ожидаемый результат — результат, который мы хотели / ожидали увидеть
• Серьезность — показывает, насколько серьезные последствия от дефекта с точки зрения влияния на систему

Уровень дефектов

• Блокирующий (Blocker) – дефект полностью блокирует выполнение функционала, нет никакого способа его обойти
• Критический (Critical) – дефект блокирует часть функциональности, но есть альтернативный путь для его обхода
• Значительный (Major) – дефект, указывающий на некорректную работу части функциональности. Зачастую связан не с тем, что функция не работает, а с тем, что она работает неправильно. В любом случае, существует более одной точки входа для инициации нужной функциональности
• Незначительный (Minor) – дефект, не относящийся к функциональности системы. Обычно серьезность Minor проставляется для тех дефектов, которые относятся к удобству использования или интерфейсу
• Тривиальный (Trivial) – дефект, не затрагивающий функциональность системы, а также оказывающий минимальное влияние на общее качество системы. Часто неотличим от уровня Minor

Самостоятельная работа

Git — это инструмент для версионирования файлов. Он используется в разработке, чтобы коллективно писать программы и сливать изменения. Больше всего Git похож на Google Docs: мы можем вернуть в любой момент времени любую версию документа, посмотреть изменения, объединить их.

GitHub — это крупнейшее хранилище Git-репозиториев, а также центр сотрудничества для миллионов разработчиков и проектов. Огромный процент всех репозиториев хранится на GitHub, а многие проекты с открытым исходным кодом используют его ради Git-хостинга, баг-трекера, рецензирования кода и других вещей.

GitHub позволяет управлять проектами, создавать баг-репорты, вести документацию. Напрямую с Git вы не будете работать, а лишь воспользуетесь возможностью создавать баг-репорты. В Github система учета ошибок называется Github Issue. Она достаточно простая, позволяет задавать заголовок, тело сообщения, теги и назначать ответственных. Этой системы достаточно, чтобы потренироваться в составлении баг-репортов.

Задача

Зарегистрируйтесь на GitHub. Составьте баг-репорт на любой баг. Попробуйте самостоятельно найти баг в любом приложении. Самое главное тут — попрактиковаться в составлении баг-репорта. Поэтому можете описать даже несуществующий баг.

Используйте для баг-репорта следующий шаблон. Он написан на языке разметки Markdown, подробнее про него можно прочитать в нашем гайде. Если хотите поэкспериментировать с Markdown, можете воспользоваться редактором Dilinger.

Перейдем к баг-репорту. Назовите свой документ по такому принципу:

# Bug: `Сюда впишите название бага`

Затем идите по этому шаблону:

## Summary

Короткое описание ошибки

## Environment

Ссылка на билд или коммит, версия ПО и всего окружения

## Steps to reproduce

Полный перечень шагов для воспроизведения

## Expected result

Какой результат должен был быть без ошибки

## Actual result

Какой результат получился на самом деле

Когда текст будет готов, перейдите в репозиторий https://github.com/hexlet-components/ru-my-first-issue.

В этом репозитории добавьте новый issue для своего баг-репорта. Для этого перейдите на вкладку Issues и нажмите New issue. Выберите готовый шаблон баг-репорта и заполните его нужными данными.

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

Если в баг-репорте есть ошибки, то появится об этом комментарий в issue. В этом случае отредактируйте issue, исправьте ошибки и сохраните изменения.

Дополнительные материалы

1. Как создать Issue на Github