В самом начале карьеры тестировщика я сталкнулся с тем, что не смог найти нормального примера оформления баг-репорта. Почти все советы в интернете на столько общие и размытые, что толку от них никакого. Пришлось потратить дофига своего времени на тупую работу – просмотреть все эти рекомендации и шаблоны чтобы отжать "воду" и собрать свой шаблон баг-репорта. Итак, баг-репорт – это запись о найденом дефекте в программе. Вещь очень нужная для всех: разработчикам понятно что не так с приложухой, а мне баг-репорт нужен чтобы через неделю я смог вспомнить что тут вообще происходило. Для менеджеров на первый взгляд баг-репорты не важны, но это не так...

Прошлая часть: Что такое тест-план? И почему было бы неплохо если бы у вас он был... Всем привет. Небольшое предисловие. Данная глава получилась немного большой, поэтому если у вас есть желание ознакомиться только с какими-то конкретными ее частями - пользуйтесь поиском по странице по ключевым словам ниже: "Основные атрибуты / поля бага"; "Приоритет и серьезность"; "Статус бага и жизненный цикл бага"; "Для кого на самом деле оформляется баг-репорт". Теперь по теме. По стандарту, пройдемся по определениям...

Когда тестировщик находит ошибку в программе или на сайте, он оформляет баг-репорт — документ, который помогает разработчикам понять и исправить проблему. Но чтобы баг был исправлен быстро и правильно, важно корректно его классифицировать. Давайте разберёмся, какие поля должны быть в баг-репорте и как правильно определять серьёзность и приоритет ошибки. Некоторые компании объединяют «Окружение» и «Версию приложения», но лучше указывать их отдельно — так информация будет точнее. Серьёзность показывает, насколько баг мешает работе пользователя...