Всего за 0.01 руб. Купить полную версию
Для примера вернемся к рассмотренной ранее программе для создания и управления тест-планами. Например, мы видим баг при копировании тестового набора (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) Спиннер исчезает по окончании процесса копирования
Очень часто увиденный результат и ожидаемый отличаются не только отрицанием, как в этом примере (появилось – не появилось, выполнилось – не выполнилось). Рассмотрим другой пример. Допустим, нас не устраивает набор тест-планов, доступных в выпадающем списке "Целевой тест-план":
Увиденный результат: Выпадающий список содержит все тест-планы
Ожидаемый результат: Выпадающий список содержит только тест-планы, которые доступны текущему пользователю.
В этом случае также важно снабдить программиста примером данных, чтобы он мог проверить свой фикс, например:
Ожидаемый результат: Пользователю "tester@email.com" доступны только тест-планы "Test-Plan1" и "Test-Plan2".
Несколько общих советов по написанию баг-репорта
– Избегайте сложных предложений и причастных/деепричастных оборотов. Разбивайте предложения на части.
– Сокращайте очевидные действия. Например, Вы тестируете графический редактор. Он доступен на странице "Редактирование и Просмотр". В баг-репорте можно опустить очевидные шаги:
Авторизуйтесь на сайте
Перейдите на страницу "Редактирование и Просмотр"
Запустите редактор
– Сводите все действия к элементарным вещам: нажатиям кнопок, перемещению мыши, вводу с клавиатуры. Например, не стоит писать фразы типа "Заблокируйте контент", лучше написать "Нажмите кнопку [Блокировать]".
– Используйте общепринятые термины. Если в вашей команде заполнитель для текстового поля все называют Placeholder, то и Вам стоит его так называть. Это особенно актуально для команд, работающих на английском языке. Со временем Вы заметите, что команда использует ограниченный набор слов. С осторожностью вводите в общий лексикон новое слово. Это может привести к двусмысленности.
– Проверьте необходимость каждого шага. Каждый лишний шаг сбивает с толку.
– Отвечайте за каждое слово. Если пишете, что баг воспроизводится для администратора, то проверьте, что он воспроизводится только для него и не воспроизводится для других ролей. Так же и с браузером – если Safari Mac, значит только Safari Mac и вы проверили во всех остальных браузерах.
– Любой баг воспроизводите с несколькими примерам. Например, пробуйте то же самое действие несколькими пользователями. Если баг воспроизводится не всеми пользователями, то попытайтесь установить разницу. Если ее нет, то, скорее всего перед Вами Data issue – это баг, который связан с нарушением целостности данных, а не с кодом. В любом случае, нужно указать аккаунт, для которого баг воспроизводится. Во-первых, программист не потратит время, напрасно пытаясь его воспроизвести. Во-вторых, Вы точнее локализуете баг, что упростит его починку.
– Заводите баг только в том случае, если поведение системы противоречит требованиям. Если в требованиях этого нет, то обсудите его в команде или напишите письмо клиенту. Избегайте субъективных суждений. Бывает так, что программисты чинят то, что на самом деле не было сломано. Потом все переделывают, по просьбе тестировщика, который думает по-другому и т.д.
– Добавляйте скриншоты к описанию бага. На них выделяйте цветной рамкой то, что Вы считаете неправильным. Другому человеку будет совсем неочевидно понять, что не так на картинке без комментария. Также добавляйте скриншот того, чего Вы хотите увидеть (его можно нарисовать в графическом редакторе или подправить верстку сайта в средствах разработчика вашего браузера). В идеале совместить эти рисунки в одном.
Словарь
При заведении бага иногда не хватает слов для точного описания проблемы. Далее приведен небольшой словарь, состоящий из наиболее часто употребляемых и общепринятых терминов.
Spinner, Loading wheel – небольшая анимированная картинка, говорящая что идет загрузка, сохранение данных, поиск или любая другая операция
Progress Bar – тоже самое что и Spinner, но еще показывает на сколько процентов завершена загрузка.
Footer – Нижняя часть страницы. Обычно содержит контакты, ссылки на группы в социальных сетях, копирайт,
Title – Заголовок страницы. Определяет текст, который будет написан на табе браузера, если в ней открыта текущая страница.
Label – Подпись элемента, чаще всего элемента управления, например, текстового поля.
Tooltip – Всплывающая подсказка, появляется при наведении на элемент
Placeholder – Текст заполнитель. Он показан, когда в текстовое поле ничего не введено. Пропадает при установке фокуса в поле.
Credentials – Совокупность логина и пароля.
Scroll bar – Полоса прокрутки
Pagination – Разбиение одной страницы на несколько маленьких.
Popup – Всплывающее окно. Обычно является модальным, то есть невозможно как либо повлиять на страницу, если оно открыто.
Alert – Модальное окно с сообщением. Посетитель не сможет продолжить работу, пока не нажмет на кнопку "ОК" в модальном окне.
Dialog box – Всплывающее окно с вопросом и несколькими вариантами ответа. Выбор влияет на дальнейшую работу страницы.
Message – Информационное сообщение. Обычно не требует никаких действий от пользователя
Pin button – Кнопка, которая фиксирует движущиеся части страницы в одном положении.
Developer tools
Почти все браузеры имеют встроенные средства разработки. Для их включения нужно нажать клавишу F12. Большинство из них позволяет делать следующее:
Просматривать и редактировать разметку страницы (html) и стили, которые к ней применились (css)
Просматривать скрипты (javascript), которые были загружены вместе со страницей