А. Не рекомендуется отсылка к внешнему документу.

Когда мы говорили о выносе части шагов в Пособие для тестировщиков, то делали это в случаях многократно по­вторяющихся сценариев, встречающихся в разных тест-комплектах, с целью сделать наш тест-кейс более поддер­живаемым. С идеей же тест-кейса и ожидаемым результа­том — совсем другая история.

Пример

Подумайте, удобно ли будет исполнять тест-кейс, если в секции IDEA напечатано:

«В этом тест-кейсе мы проверяем пункт 21.6 спека номер 34 "Сцена­рий добавления кредитной карточки к счету пользователя"»

или в секции Expected Result:

"Проверь, что значение последнего шага равно значению пересечения значения шага 5 по оси X и значению шага 23 по оси Y из таблицы 17.0 спека из секции IDEA"?

б. Нужно помнить, что суть секции IDEA — это ОБЪЯСНЕ­
НИЕ идеи тест-кейса.

Пример

Если секция IDEA пуста или же в ней скромно напечатано "10", то каж­дый исполняющий этот тест-кейс каждый раз будет тратить несколько минут своего времени и/или времени своего коллеги на выяснение того, что же проверяется этим тест-кейсом.

в. Нужно помнить, что ожидаемый результат — это ин­
формация, на основании которой (вкупе с фактическим
результатом) мы принимаем решение об исходе тест-
кейса. Следовательно, точность и четкость в форму­
лировке ожидаемого результата играют наиважнейшую
роль.

Пример

Ожидаемый результат гласит: "Проверь, что показана страница с ошибкой", и страница с ошибкой действительно показывается. Дело в том, что если показывается не та ошибка, которая положена по специ­фикации, то будет пропущен баг. Почему он будет пропущен? Пра­вильно: из-за неточной формулировки ожидаемого результата.

Еще один пример плохого ожидаемого результата:

"Все работает".

Идем дальше.

Искусство создания тест-кейсов

Тест-комплекты

С помощью каждого отдельно взятого тест-кейса проверяется какая-то одна вещь (развернуто сформулированная в секции IDEA). Каждый спек — это источник для множества идей тести­рования, и, таким образом, для проверки кода, написанного в со­ответствии со спеком, нам нужно множество тест-кейсов.

Совокупность тест-кейсов (находящихся, как правило, в одном документе), которые проверяют

• какую-то определенную часть нашего интернет-проекта

(например, "Оплату") и/или

• определенный спек (например, спек номер 1455 "Рассылка
пользователям е-мейлов на основании истории заказов"),

называют тест-комплектом (test case suite).

Что происходит в жизни?

• получаем новый спек;

• создаем новый файл, в котором создаем новые тест-кейсы для этого нового спека;

• исполняем новые тест-кейсы с их одновременной модифи­кацией (об этом через 45 секунд);

• если имеет смысл, то переносим тест-кейсы в основной тест-комплект, где хранятся тест-кейсы, проверяющие ту же функциональную часть вашего интернет-проекта.

Создание нового файла с новым тест-комплектом обусловлено тем, что новые тест-кейсы всегда исполняются в первую оче­редь и нам просто удобно хранить их отдельно от старых. Как говорится, "мухи отдельно, котлеты отдельно" (конечно, до тех пор, пока нам это удобно).

Пример

На www.testshop.rs можно производить оплату картами VISA и Master­Card. У нас есть тест-комплект, который мы исполняем из релиза в ре­лиз (это регрессивное тестирование, о котором мы еще будем много говорить), называемый "Покупка с использованием кредитных карт".

Этот тест-комплект был написан на основании спека #1211 и содержит тест-кейсы для проверки функциональностей оплаты с использовани­ем VISA и MasterCard.

Для нового релиза написан спек #1422, согласно которому будет на­писан код для поддержки новой карты — британской Switch.

56 Тестирование Дот Ком. Часть 1

Сначала создаем новый тест-комплект "Покупка с использованием Switch", затем исполняем и одновременно модифицируем его. Учиты­вая, что

• после исполнения содержимое тест-комплекта будет стабили­зировано и

• в нем проверяется та же функциональная часть веб-сайта ("Оп­лата"),

в данном случае будет логичным сделать его частью тест-комплекта "Покупка с использованием кредитных карт".

Дата добавления: 2015-12-07