tестирование dot com

пенно ваши тест-кейсы будут либо хиреть без поддержки, либо потреб-

лять на поддержку уйму времени.

Пример

А что, если не имя кнопки, а сам путь, по которому вы добираетесь до

фактического результата, претерпел изменения? Например, шаги 7 и 9

станет разделять не линк "Корзина", а еще несколько дополнительных

линков и кнопок, появившихся в новой версии www.testshop.rs.

В общем проблема понятна. И имя ее — maintainability (поддер-

живаемость), т.е. насколько легко и просто можно изменить

тест-кейс при изменениях в ПО. Не думать о поддерживаемо-

сти тест-кейсов — значит не думать о завтрашнем дне, что, не-

смотря на полезность для духовной жизни, все-таки плохо для

бизнеса.

Если мы разобьем шаги нашего нового тест-кейса с картой на ло-

гические модули, получим:

1. Вход в систему (логин — log in).

2. Поиск товара.

3. Добавление товара в корзину.

4. Оплата.

5. Фиксация номера заказа.

6. Запрос базы данных.

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

45

Почему бы нам не выбросить из тест-кейса детали по следующим

позициям?

1. Вход в систему

В общем-то можно догадаться, куда ввести имя пользователя,

куда пароль и на какую кнопку нажать, тем более что в данном

случае мы не тестируем процесс логина, это было или будет сде-

лано при исполнении соответствующего тест-кейса, сейчас мы

просто грубо и бесцеремонно используем логин, легкомысленно

надеясь, подобно покупателю российского автопрома, что все

будет чики-пики.

2. Поиск товара

Все из предыдущего пункта применимо и здесь. Кроме того, до-

пустим, что book117 была удалена из нашей базы данных подлы-

ми завистниками и подхалимами. Что же нам — в отчаянии рвать

на себе волосы и кричать, что мы заблокированы? Нет, мы просто

превентируем такую ситуацию тем, что не будем давать имени

конкретного товара. Что найдется, то найдется (так как то, что

найдется, в данном случае значения не имеет).

3. Добавление товара в корзину

Концепция из "1. Вход в систему" применима и здесь.

4. Оплата

Концепция из "1. Вход в систему" применима и здесь.

О'к, с оплатой я, пожалуй, немного переборщил — не факт, что

будет абсолютно очевидно, как провести ее, и шаги все же потре-

буются.

Здесь появляется другая загвоздка: если мы производим оплату в

сотнях тест-кейсов, т.е. сотни раз включаем в тест-кейс те же

семь шагов (8—14 включительно), то при изменении даже в од-

ном из этих шагов нам придется переписывать эти сотни тест-

кейсов...

Не проще ли вынести шаги, повторяющиеся от тест-кейса к

тест-кейсу, во внешний документ и вместо них включить в

тест-кейс лишь один шаг-ссылку «Произведи ОПЛАТУ

КАРТОЙ из секции "SETUP and ADDITIONAL INFO"»? Поступив

46

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

таким образом, мы сэкономим громадное количество часов рабо-

чего времени, так как при необходимости менять шаги нужно

будет только в одном месте!

Кстати, "оплата картой" — это линк к страничке в локальной сети с со-

ответствующей инструкцией, называемой, например, "Как произвести

оплату кредитной картой".

Кстати, хорошей идеей является создание в локальной сети вашей

компании мини-веб-сайта департамента качества, где наряду с веб-

страничками с

• контактной информацией работников департамента,

• пинками к файлам с тест-комплектами,

• другой полезной информацией

расположится и внутреннее Пособие для тестировщиков (QA Knowl-

edge Base), где кроме прочего будут задокументированы повторяю-

щиеся сценарии.