Шрифт:
ния. А что, если у нас 500 тест-кейсов, где упоминается кнопка "Войти",
и эти тест-кейсы разбросаны по разным документам, как мои одно-
классники по свету? Вносить 500 изменений? Скажете: "Ерунда, можно
догадаться". Но таких маленьких изменений будут десятки!!! И посте-
пенно ваши тест-кейсы будут либо хиреть без поддержки, либо потреб-
лять на поддержку уйму времени.
Пример
А что, если не имя кнопки, а сам путь, по которому вы добираетесь до
фактического результата, претерпел изменения? Например, шаги 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