Репорты
- Отчет должен быть понятным
- Текст не должен содержать абстракций
- Текст в техническом стиле
- Скриншоты и видеозаписи
- Единство оформления
- Диаграммы, графики, статистика
- Не должно быть повторяющихся багов
- У каждого бага должен быть свой id
- Баг должен быть воспроизводимым
Не использовать командный тон (без резких слов) в отчете. Не нужно указывать на ошибку разработчика, нужно быть толерантным.
Test report
Отчет по проведенному тестированию (Сколько тестов было проведено, сколько успешно/неуспешно, сколько багов найдено и т.д., т.е. со всеми бозовыми метриками). Временной, итерационный (Месячный, недельный, ежедневный).
- Информация о проекте
- Список специалистов-тестировщиков со своими зонами ответственности
- Описание процесса тестирования (по тест-плану, если есть)
- Краткое описание, расписание тестирования
- Деффекты, лучше показывать на диаграммах
- Новые зафиксированные и устраненные деффеекты
- Заключение о качестве работы продукта по результатам тестирования
- Рекомендации
Bug report
Документация багов. Более детальный отчет по всем найденным багам с подробностями к воспроизведению.
Визуально оформление баг-репорта похоже на тест-кейс.
Пример баг-репорта
| ID | Title | Severity | Priority | Author | Enviroment | Precondition | Steps | Expected result | Observed result | Atachments | Comments |
|---|---|---|---|---|---|---|---|---|---|---|---|
| B1 | Отсутствуют паддинги в карточке товара | S3/Значительный | E.Leukhin | PC, Windows 11, Chrome 105 | Открыть каталог товаров | Сравнить дизайн карточек | Дизайн соответствует | Дизайн не соответствует | Some files | Some comments |
Примерные колонки в баг-репорте
Обязательные
- id
- title (Заголовок ошибки)
- severity
- priority (тестровщик не заполняет, заполняет PM)
- author - Автор баг-репорта
- enviroment (сервер dev, stage, prod)
- precondition
- steps - Шаги по воспроизведению
- expected result
- actual result
- comments
- atachments
Опциональные
- modules or sub-module
- версия
- description - более подробное описание
- assignment - какой разработчик будет исправлять (тестровщик не заполняет, заполняет PM)
Серьёзность (severity):
Влияние деффекта на работоспособность приложения.
- S1 (blocked) блокирующая - не работает часть функционала и нет путей обхода
- S2 (critical) критическая - не работает часть функционала, но есть пути обхода
- S3 (major) значительная - есть ошибки в работе функционала, он работает, но криво
- S4 (minor) незначительная - есть ошибка, но на функционал при этом она не влияет
- S5 (trivial) тривиальная - ошибка в орфографии, либо плохо воспроизводимая ошибка
Может бьть так, что у бага высокая severity, но низкая priority. Например, непопулятная Фотогалерея не работает.
Или наоборот, например опечатка в почтовом индексе.