Базовые знания тестировщика веб-приложений

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