И так, Вы убедились, что нашли стабильные шаги для воспроизведения, и знаете, в каких условиях воспроизводится баг. Теперь можно переходить к его описанию. Для этого Вы должны придумать название, дать шаги для воспроизведения проблемы, описать текущее поведение программы и ожидаемое.
Заголовок
Заголовок должен кратко отражать суть проблемы. По хорошему заголовку можно понять, как воспроизвести баг и что должно быть в итоге. Но прежде всего заголовок должен облегчать поиск бага. Баги приходится искать очень часто, например, при заведении нового бага, Вы должны убедиться, ни завел ли уже его кто-то из ваших коллег. Например, Вы видите такую проблему: Модератор может закрывать темы на форуме даже в тех разделах, которые ему не назначены. Все потому что ему показана кнопка [Закрыть тему]. Наверняка Вы будете пытаться найти этот баг по слову модератор или по названию кнопки, поэтому эти слова обязательно должны быть включены в заголовок.
Хороший пример:
Кнопка [Закрыть тему] должна быть доступна модератору только в темах его раздела
Плохие примеры:
Модератор может закрыть любую тему
Кнопка [Закрыть тему] должна быть скрыта
Лишние кнопки доступны модератору
Существует хорошая практика добавлять в заголовок бага название той области, где он был найден. Это также облегчает поиск и позволяет программистам скорее распределять баги между собой. Например:
Права пользователей: Закрытие темы - Кнопка [Закрыть тему] должна быть доступна модератору только в темах его раздела
После того, как фича будет отдана на тестирование клиенту, в ней делают небольшие изменения/улучшения. Иногда информацию об этих изменениях забывают внести в документацию. Допустим, спустя некоторое время Вам потребуется тестировать эту фичу вновь. Вы откроете документ и обнаружите, что он отличается от того, что Вы видите на деле. Единственным источником актуальной информации для Вас будет баг-трекер. Просмотрев заголовки багов, Вы сможете понять, что было сделано. В этом случае Вам будет удобнее, если заголовки будут написаны в повелительном наклонении, то есть в них будет описание того, что должно быть, а не то, что видит тестировщик. Такой подход также облегчает программисту жизнь – он точно знает, чего от него хотят.
Хорошие примеры:
Ширина кнопки [Like] должна быть 50 px
Фон домашней страницы должен быть синим
Диалог “Создание нового пользователя” должен быть показан при нажатии на кнопку [Регистрация]
Плохие примеры:
Кнопка [Like] слишком узкая
Фон домашней страницы не должен быть красным
Кнопка [Регистрация] не работает
Программисты одобряют такой подход. Им становится легче понять то, чего от них хотят.
Предусловия
Иногда при заведении бага Вы можете обнаружить, что описание включает очень большое количество шагов (больше 5). Это делает баг трудным для понимания и воспроизведения. Очень часто это случается, если тестировщик пытается описать то, как он создавал какие то данные, необходимые для воспроизведения бага.
Для примера вернемся к рассмотренной ранее программе для создания и управления тест-планами. Например, мы видим баг при копировании тестового набора (test suite), в котором 10 тест-кейсов. Тестировщик может попытаться завести баг следующим образом:
1) Открой страницу создания и управления тест-планами.
2) Создай тест-план
3) Добавь в него тестовый набор
4) Добавь в тестовый набор 10 тест-кейсов
5) Выбери тестовый набор и нажми кнопку [Копировать]
В этом примере тестировщик описывает процесс создания 10 тест-кейсов. Тест-кейсы – это статичные данные, которые хранятся в базе данных. Не нужно описывать процесс создания в баге где проблема в копировании. Поэтому, если для воспроизведения бага нужны какие-то данные, то просто дайте их словесное описание. Такое описание данных и состояние системы, которое необходимо для воспроизведения бага называется предусловиями (preconditions, prerequisite). Вот как могут выглядеть предусловия для нашего примера:
Предусловия: Тестовый набор содержит 5 и более тест-кейсов
Пример в тестовой среде: Тестовый набор ID = 241, Имя = “10ТестКейсов”
Шаги:
1) Открой страницу создания и управления тест-планами.
2) Выбери тестовый набор из предусловий
3) Нажми кнопку [Копировать]
Если баг требует предусловий, то подготовьте и пример данных из предусловий. Это упростит жизнь программисту – ему не придется делать дополнительную работу, а также на готовом примере ему будет легче разобраться в сути.
Наличие примера также подстраховывает Вас от ошибки в описании. При описании бага с более сложными предусловиями очень легко пропустить какую-нибудь важную деталь, но с помощью примера всегда можно будет разобраться в проблеме. Если баг воспроизводится на какой то определенной странице, то обязательно дайте прямую ссылку на эту страницу (иногда тестировщики описывают последовательность переходов, но это только запутывает). Не стоит заводить баги, где есть только пример, но нет описания предусловий. Пример может быть удален или кому то потребуется воспроизвести баг в другой среде, где нет этого примера.
В баг-репорт можно добавлять замечания (Notes). Обычно в них указывают дополнительные сведения, на которые нужно обратить внимание. Например, туда можно вынести текст ошибки или выдержку из требований к той части проекта, где баг.
Также можно дополнить описание шагов для воспроизведения наблюдениями (Observation). Они упрощают понимание шагов и иногда помогают избежать повторений текста. Пример описания процесса копирования:
1) Открой страницу создания и управления тест-планами.
2) Выбери тестовый набор из предусловий
3) Нажми кнопку [Копировать]
Наблюдение 1: Появился диалог “Копирование Тестового Набора”
4) Выберите любой тест-план в выпадающем списке “Целевой тест-план”
5) Нажмите кнопку [Ок] в диалоге
Наблюдение 2: Процесс копирования начался, на странице появился спиннер
Результаты
Финальной частью баг-репорта является описание увиденного результата (Actual Results) и ожидаемого (Expected Results). В увиденном результате последовательно опишите, что произошло после выполнения всех шагов. В ожидаемом результате – то, что хотите увидеть. Ожидаемый результат должен основываться на требованиях к проекту. Например:
Увиденный результат:
1) Копия тестового набора не появилась в целевом тест-плане
2) Спиннер не исчезает
3) Ошибка в консоли браузера
Ожидаемый результат:
1) Копия тестового набора появилась в целевом тест-плане
2) Спиннер исчезает по окончании процесса копирования
Очень часто увиденный результат и ожидаемый отличаются не только отрицанием, как в этом примере (появилось – не появилось, выполнилось – не выполнилось). Рассмотрим другой пример. Допустим, нас не устраивает набор тест-планов, доступных в выпадающем списке “Целевой тест-план”: