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

В этом примере тестировщик описывает процесс создания 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) Спиннер исчезает по окончании процесса копирования

Очень часто увиденный результат и ожидаемый отличаются не только отрицанием, как в этом примере (появилось – не появилось, выполнилось – не выполнилось). Рассмотрим другой пример. Допустим, нас не устраивает набор тест-планов, доступных в выпадающем списке “Целевой тест-план”:

Увиденный результат: Выпадающий список содержит все тест-планы

Ожидаемый результат: Выпадающий список содержит только тест-планы, которые доступны текущему пользователю.

В этом случае также важно снабдить программиста примером данных, чтобы он мог проверить свой фикс, например:

Ожидаемый результат: Пользователю “[email protected]” доступны только тест-планы “Test-Plan1” и “Test-Plan2”.

Несколько общих советов по написанию баг-репорта

– Избегайте сложных предложений и причастных/деепричастных оборотов. Разбивайте предложения на части.

– Сокращайте очевидные действия. Например, Вы тестируете графический редактор. Он доступен на странице “Редактирование и Просмотр”. В баг-репорте можно опустить очевидные шаги:

Авторизуйтесь на сайте

Перейдите на страницу “Редактирование и Просмотр”

Запустите редактор

– Сводите все действия к элементарным вещам: нажатиям кнопок, перемещению мыши, вводу с клавиатуры. Например, не стоит писать фразы типа “Заблокируйте контент”, лучше написать “Нажмите кнопку [Блокировать]”.

– Используйте общепринятые термины. Если в вашей команде заполнитель для текстового поля все называют Placeholder, то и Вам стоит его так называть. Это особенно актуально для команд, работающих на английском языке. Со временем Вы заметите, что команда использует ограниченный набор слов. С осторожностью вводите в общий лексикон новое слово. Это может привести к двусмысленности.

– Проверьте необходимость каждого шага. Каждый лишний шаг сбивает с толку.