3. Приоритет и серьезность
4. Шаги воспроизведения
5. Ожидаемое поведение
6. Фактическое поведение
7. Сопроводительные аттачи (скриншоты/скринкасты)
Пойдем по порядку.
Заголовок
Это первое, что видит любой пользователь таск-трекера. Заголовок должен быть написан так, что прочитав, становится понятно, в чем проблема. В идеале ваш заголовок должен как можно короче ответить на 3 вопроса: Что? Где? Когда?
Что? Пропадает кнопка входа.
Где? В форме регистрации – иногда вопрос Где? становится избыточным, и его можно опустить.
Когда? При нажатии на поле ввода пароля.
Нельзя расписывать заголовок более чем на одно среднее предложение, это только тормозит работу – и вашу, и того, кому придется читать заголовок. На планированиях и грумингах менеджеры вместе с разработчиками разбирают завалы задач, выбирая, что взять в работу в ближайшее время, а что может подождать. Никто не любит эти встречи (поверьте!), так что пишите заголовки настолько коротко и понятно, насколько можете.
Окружение
Сюда входит все, что помогает локализовать ваши условия воспроизведения бага. На каком девайсе вы поймали ошибку? Какая iOS у вас установлена? Какая версия приложения используется? Если баг сетевой, какую сеть вы использовали? Может влиять и оператор связи, поэтому, укажите его, если подозреваете, что в этом кроется причина ошибки. Распишите как можно подробнее, и разработчику не придется задавать вам вопросы поверх вашего баг-репорта.
К окружению мы также относим предусловия. В предусловиях описываются действия, которые нужно выполнить, и параметры, которые нужно применить перед выполнением шагов, позволяющих воспроизвести баг. Это описание не имеет какого-то четкого формата, просто придерживайтесь логического порядка. Многие пишут предусловия отдельным пунктом, но мы предпочитаем объединять их с окружением для упрощения.
Приоритет и серьезность
Приоритет является атрибутом, определяющим необходимую скорость устранения бага.
Первоначально приоритет бага определяется инициатором, но затем он корректируется менеджером продукта. Именно менеджер имеет общее представление о тестируемой системе и понимает, насколько срочно нужно исправить тот или иной баг.
Виды приоритетов:
1. Top. Назначается экстренным ситуациям, которые очень отрицательно влияют на продукт или даже бизнес компании. Такие баги нужно устранять немедленно.
2. High. Назначается багам, которые должны быть устранены в первую очередь.
3. Normal. Обычный приоритет, назначается по умолчанию. Эти баги устраняются во вторую очередь, в штатном порядке.
4. Low. Назначается багам, не влияющим на функциональность. Исправление таких багов происходит в последнюю очередь, если есть время и ресурсы.
Серьезность – это атрибут, характеризующий влияние бага на общую функциональность тестируемого продукта.
Степень серьезности бага больше касается функциональности, поэтому она присваивается тестировщиком. Именно он чаще всего оценивает, насколько конкретная функция может влиять на общую работу тестируемого продукта.
Пример классификации серьезности багов:
1. Blocker. Блокирующая ошибка. Она делает невозможной всю последующую работу с программой. Для возобновления работы нужно исправить Blocker.
2. Critical. Критическая ошибка. Нарушает работу основной функциональности. Баг проявляется постоянно и делает невозможным использование основных функций программы.
3. Major. Существенный баг. Затрудняет работу основной функциональности или делает невозможным использование дополнительных функций.
4. Minor. Незначительный баг. На функциональность системы влияет относительно мало, затрудняет использование дополнительных функций. Для обхода этого бага могут быть очевидные пути.
5. Trivial. Тривиальный баг. Не влияет на функциональность проекта, но ухудшает общее впечатление от работы с продуктом.
Существуют практики, когда два атрибута объединяются в один – приоритет – и устанавливаются тестировщиком. В таком случае любому другому участнику релизного процесса запрещено изменять приоритет без обсуждения с инициатором баг-репорта.
Шаги воспроизведения
Наилучшим способом описания шагов воспроизведения ошибки является составление пронумерованного списка с последовательностью действий пользователя, приводящих к проявлению ошибки. Используйте простые предложения, например:
1. Пользователь открывает вкладку «Статистика».
2. Нажимает на кнопку «Сохранить».
3. Обновляет страницу.
Фактический результат
Фактический результат – это проблема, которая возникает, когда пользователь выполняет шаги, указанные выше. Опишите результат, указав, что происходит, где и когда. Это поможет разработчику понять проблему. Краткое и четкое описание пригодится также команде тестирования в будущем.
Ожидаемый результат
В этом разделе опишите ожидаемый результат шагов. То есть, изложите, как приложение должно было бы себя вести. Ошибка также может быть ожидаемым результатом, если тестировщик проверяет негативный сценарий. Например, если пользователь вводит неправильные учетные данные, он не должен войти в систему, вместо этого он должен увидеть сообщение об ошибке.
Прикрепленные файлы
Это дополнительные материалы, которые можно добавить к баг-репорту. Часто с визуальными руководствами бывает проще воспроизвести баг. Особенно, если баг сложно описать словами. Добавление скриншотов или коротких видео поможет избежать недопонимания. Только не забывайте, что визуальные материалы должны быть релевантными и понятными.
Составление тестовой документации
Тестовой документацией называется набор проверок, регулярно исполняемых в ходе релизного цикла. Если вы когда-либо интересовались авиацией, здесь довольно много аналогий. Если рейс – это релиз, то авиаконструкторы – это разработчики, пассажиры – пользователи, то экипаж воздушного судна – это тестирование, релиз-менеджмент и поддержка пользователей. Перед самым взлетом вы можете слышать, как по бортовой связи старший бортпроводник передает «внимание бортпроводникам – двери в положение armed, cross-check». Экипаж блокирует двери самолета и перепроверяет друг друга. Это всего лишь маленький фрагмент предполетных проверок, которые проходит экипаж.
Управление воздушным судном требует безоговорочного выполнения всех инструкций для сохранения всех пассажиров и членов экипажа, которые находятся на борту самолета. На каждый этап полета разработаны чек-листы, которые экипаж обязан зачитывать каждый полет.
Что из себя представляет чек-лист? Это перечень требуемых конфигураций самолета, для безошибочного выполнения полета. Пилоты – это, в первую очередь, люди. С каждым новым полетом все действия начинают выполняться «на автомате», но может случиться непоправимое, если, например, при посадке забудут выпустить шасси… Для того, чтобы это не допустить, и были разработаны чек-листы.
Например, при подготовке самолета к посадке, командир воздушного судна начинает зачитывать чек-лист:
– Шасси выпущены.
Второй пилот проверяет, запущены ли шасси. В случае утвердительного ответа КВС зачитывает следующий пункт.
