testirovanie_dot-com

Постановка мозгов

Front end (читается как "фронт-энд") — это непосредственный интерфейс пользователя, т.е. текст, картинки, кнопки, линки и прочие вещи, которые пользователь видите окне веб-браузера или е-мейл клиента.

Back end (читается как "бэк-энд") — это ПО и данные, находящиеся за фасадом фронт-энда: HTML-код веб-страницы, веб-сервер, код приложения, база данных и т.д.

Впоследнем примере мы непосредственно "разговаривали"

•с фронт-энд ом —в шаге5, когда добавляли товарв корзину;

•с бэк-эндом — в шаге 8, когда запрашивали базу данных.

Проблемные тест-кейсы

Теперь посмотрим, какие недостатки вы должны выжигать из своих тест-кейсов каленым железом.

1.Зависимость тест-кейсов друг от друга.

2.Нечеткая формулировка шагов.

3.Нечеткая формулировка идеи и/или ожидаемогорезультата.

1.ЗАВИСИМОСТЬ ТЕСТ-КЕЙСОВ ДРУГ ОТ ДРУГА

Зависимость — это антоним независимости. Независимость тесткейса выражается в том, что он не связан с другими тест-кейсами.

Пример

Тест-кейс 1:

Шаги:

1.Зайти в комнату.

2.Подойти к стулу.

3.Открыть правый внешний карман рюкзака.

4.Засунуть руку в правый внешний карман рюкзака. Ожидаемый результат: Граненый стакан.

Тест-кейс 2:

Шаги:

1.Зайти в комнату.

2.Подойти к стулу.

3.Открыть левый внешний карман рюкзака.

4.Засунуть руку в левый внешний карман рюкзака. Ожидаемый результат: Огурец.

Как видно, шаги 1 и 2 сейчас одинаковы и всегда будет искушение улучшить то, что и так хорошо.

Как результат, во всех трех случаях мы не можем исполнить тесткейс Y, так как данных, на которые он опирается, просто не существует.

Таким образом, хороший тест-кейс характеризуют:

•отсутствие ссылок на другие тест-кейсы;

•независимость от "следов", оставленных другими тесткейсами в нашем ПО или базе данных.

Следовательно, если у нас в документе А есть 10 тест-кейсов: тест-кейс 1, тест-кейс 2, ..., тест-кейс 10, то доказательством независимости каждого из тест-кейсов будет тот факт, что их без ущерба для тестирования можно всегда исполнять в любом порядке, например, тест-кейс 10, затем тест-кейс 2, затем тесткейс 6 и т.д. Принцип, думаю, понятен.

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

2. НЕЧЕТКАЯ ФОРМУЛИРОВКА ШАГОВ

Пример

"Пойди туда,незнаюкуда".

На шаги тест-кейса можно смотреть, как на инструкцию "Как пройти" (или "Как проехать").

Пример

Если американцу, который в Москве первый раз, сказать (с видом москвича в пятом колене), что Красная площадь находится "за ГУМом", то он бессмысленно потратит много времени в поисках "загума" в путеводителе. Если же черкнуть емуе-мейльчикс инструкцией:

1.Выйди из "Националя".

2.На улице поверни направо.

3.Не поднимая глаз, пройди мимо первой стайки барышень.

4.Не поднимаяглаз, пройдимимовторойстайки барышень.

5.Спустись налево в подземный переход.

6.Следуй указателям на стенах снадписью "Краснаяплощадь",

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

Кстати,

•шаги 1 — 5 включительно — это точные инструкции, а

•шаг 6 — это отсылка к инструкциям, хранящимся в другом месте (помните, мы говорили о внутреннем Пособии для тестировщи-ков с шагами для повторяющихся сценариев?).

Итак, перечисляющиеся в тест-кейсе шаги должны быть объ-

ективно четкими и ясными.

Нужнопомнить,

•то, что очевидно для вас сейчас, может стать совершен но непонятным через пару месяцев.

Так, сокращенные шаги с нерасшифрованными аббревиатурами и прочими веселыми прибамбасами, понятными вам сейчас, могут впоследствии стать китайской грамотой для вас самих, так что проще будет написать тест-кейс заново, чем пробираться через дебри неосмотрительно сделанных описаний;

•тест-кейс, который не может быть исполнен никем, кроме его автора, должен быть публично сожжен, рас терт в порошок и развеян по ветру.

Обоснование простое: что, если автор тест-кейса заболеет, уйдет в отпуск, уйдет из компании или уйдет, извините,

вообще? Любой тест-кейс должен создаваться с мыслью

о коллеге, который однажды возьмет его в руки.

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

В общем ищите золотую середину.

3.НЕЧЕТКАЯ ФОРМУЛИРОВКА ИДЕИ ТЕСТ-КЕЙСА И/ИЛИ ОЖИДАЕМОГО РЕЗУЛЬТАТА

Оба тезиса, о которых мы только что говорили:

•о том, что можно забыть то, что сейчас понятно, и

•писать тест-кейсы нужно не для себя, а для того парня —

применимы и к идее и к ожидаемому результату. Нюансы для идеи тест-кейса и ожидаемого результата:

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

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

Пример

Подумайте, удобно ли будет исполнять тест-кейс, если в секции 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 и MasterCard. У нас есть тест-комплект, который мы исполняем из релиза в релиз (это регрессивное тестирование, о котором мы еще будем много говорить),называемый "Покупкас использованиемкредитныхкарт".

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

ем VISA и MasterCard.

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

(TS7122)—каждыйтест-комплектдолжениметьсвойуникальныйID.