testirovanie_dot-com

•ожидаемый результат — это некий предмет, который мы должны найти, если поднимемся по этим ступенькам;

•фактический результат— это то, что мы реально нашли

после того, как поднялись по этим ступенькам.

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

ИСХОДЯ ИЗ ОСНОВНОЙ компьютерной концепции ВВОД/ВЫВОД (на языке оригинала — input/output):

•шаги — это инструкция по вводу;

•исполнение шагов — это ввод;

•ожидаемый результат — это ожидаемый вывод;

•фактический результат — это фактический вывод.

Исполнение тест-кейса завершается сравнением вывода фактического и вывода ожидаемого.

Исходисполнениятест-кейса(test case result)

Каждый тест-кейс, исполнение которого завершено, дает нам одно из двух:

1.Положительный исход (PASS), если ФР равен ОР,

либо

2.Отрицательный исход (FAIL), если ФР не равен ОР: най

ден баг!

Иногда возникает ситуация, когда мы заблокированы (test case execution is blocked), так как не можем пройти ВСЕ шаги тесткейса. Например, мы не можем продвинуться дальше, если кнопки "Завершить заказ" из шага 14 не существует на соответствующей веб-странице. В таком случае мы рапортуем баг (в данном случае баг об отсутствии кнопки "Завершить заказ") и откладываем исполнение тест-кейса до устранения бага.

Полезныеатрибутытест-кейса

УНИКАЛЬНЫЙID(UniqueID)

Это необходимая вещь. Тест-кейс без ID — это то же самое, что квартира без адреса или швейцарские часы без номера. ID должен быть уникальным в пределах не только документа, содержащего тест-кейс (об этом документе позже), но и всего департамента

Приходитдруг Лежа и, пока Макс на правах радушного хозяина несется к ларькам станции метро "Юго-Западная" и обратно, учит альтернативноймудростичестновпитывающегознанияВасю:

—"Все козлы";

—"Simia quantum similis turpissima bestia nobis!" ("Как похожа на нас мерзейшая тварь — обезьяна!");

—"Move bitch, get out theway" ("Уйди с дороги, противная").

Витоге после возвращения домой Макса встречает не добрый, милый попугайчик, а негативно настроенная машина, и вечером ему (Максу) придется доказывать своей жене, что это не он, а подлец Леха изменил лексикон бедолаги Василия.

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

где отражаем: Кто? Что? Зачем? Когда? Почему?

Атрибуты истории редактирования:

•Created on <date> by <name> — Тест-кейс создан <дата> <кем>;

•Modified on <date> by <name> — Тест-кейс изменен <дата> <кем>;

•Change — Что, зачем и почему было изменено. В наших примерах мы не печатаем само слово "change", а просто заполняем значение этого атрибута в поле справа от

"Created on..." или "Modified on...".

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

IDEA: Оплата может быть произведена картой VISA SETUP and

ADDITIONAL INFO:

Эккаунт: testuser1/paSSwOrd Наименование товара: book117 Данные карты:

Номер: 9999-5148-2222-1277

Окончание действия: 12/07 CVV2: 778

SQL1: select result from cc_transaction where id = <номер заказа>;

Revision History

Идем дальше.

Тест-кейсы, управляемые данными

Основной плюс новоготест-кейса с картой заключается в том, что

нам не нужно вносить изменения в ШАГИ, чтобы протестировать по тому же сценарию другие карты. Единственное, что нам нужно, — это модифицировать исходные ДАННЫЕ.

Таким образом, если кроме VISA нам нужно протестировать по тому же сценарию еще две карты, то мы

•делаем сору один раз;

•paste два раза;

•в каждом из новых тест-кейсов переписываем только пять подчеркнутых значений, проживающих в шапке тест-кейса и секции ожидаемогорезультата (меняемиIDтест-кейса —ТСID, который, как мы помним, должен быть всегда уникальным):

VISA 9999-5148-2222-1277 12/07 778 10

Такой вид тест-кейса называется data-driven (буквально "управ-

ляемый данными"), т.е. когда данные и инструкции по их при-

менению не смешаны, а разделены и слинкованы.

Поддерживаемость тест-кейса

Новый тест-кейс с картой хорош. Все при нем — и data-driven, и удобочитаемый формат, и полезные атрибуты. Проблема в том, что веб-сайт, а особенно его часть, именующаяся интерфейсом пользователя {User Interface или просто UI— "ю-ай"), очень часто меняется.

Пример

Кнопка "Войти" из шага 4 легко может быть переименована во "Вход". Следовательно, если у нас есть 3 тест-кейса, то нужно внести 3 изменения. А что, если у нас 500 тест-кейсов, где упоминается кнопка "Войти", и эти тест-кейсы разбросаны по разным документам, как мои одноклассники по свету? Вносить 500 изменений? Скажете: "Ерунда, можно догадаться". Но таких маленьких изменений будут десятки!!! И постепенно ваши тест-кейсы будут либо хиреть без поддержки, либо потреблять на поддержку уйму времени.

Пример

А что, если не имя кнопки, а сам путь, по которому вы добираетесь до фактического результата, претерпел изменения? Например, шаги 7 и 9 станет разделять не линк "Корзина", а еще несколько дополнительных линков и кнопок, появившихся в новой версии www.testshop.rs.

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

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

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

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

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

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

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

4.Оплата.

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

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

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

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

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

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

Все из предыдущего пункта применимо и здесь. Кроме того, допустим, что book117 была удалена из нашей базы данных подлыми завистниками и подхалимами. Что же нам — в отчаянии рвать на себе волосы и кричать, что мы заблокированы? Нет, мы просто превентируем такую ситуацию тем, что не будем давать имени конкретного товара. Что найдется, то найдется (так как то, что найдется, в данном случае значения не имеет).

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

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

4. Оплата

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

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

Здесь появляется другая загвоздка: если мы производим оплату в сотнях тест-кейсов, т.е. сотни раз включаем в тест-кейс те же семь шагов (8—14 включительно), то при изменении даже в одном из этих шагов нам придется переписывать эти сотни тесткейсов...

Не проще ли вынести шаги, повторяющиеся от тест-кейса к тест-кейсу, во внешний документ и вместо них включить в тест-кейс лишь один шаг-ссылку «Произведи ОПЛАТУ

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

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

Кстати, "оплата картой"— это линк к страничке в локальной сети с соответствующей инструкцией, называемой, например, "Как произвести оплату кредитной картой".

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

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

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

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

расположится и внутреннее Пособие для тестировщиков (QA Knowledge Base), где кроме прочего будут задокументированы повторяющиеся сценарии.

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

1.Сделать тест-кейс data-driven.

2.Не описывать шаги по явно очевидным сценариям (например, логин).

3.Не давать конкретных деталей, если они не играют роли при исполнении тест-кейса (например, имя товара).

4.Вынести во внешний документ повторяющиеся сценарии (например, семь шагов оплаты).

Ну, за поддерживаемость!

IDEA: Оплата может быть произведена картой VISA SETUP and

ADDITIONAL INFO:

Эккаунт: testuser1/paSSwOrd Данные карты: Номер: 9999-5148-2222-1277

Окончание действия: 12/07

CVV2: 778 SQL1: select result from cc transaction where id = <номер заказа>;

Revision History

Идем дальше.

Сколько ожидаемыхрезультатов может быть в одномтест-кейсе?

Тест-кейсом проверятся только одна конкретная вещь, и в идеальном варианте для проверки этой вещи достаточно предусмотреть в тест-кейсе только один ОР, и если бы я был теоретиком, а не практиком тестирования, то сказал бы, что ни в коем случае нельзя включать в тест-кейс более одного ОР.

ВОТвамслучайизпрактики

Допустим, что в соответствии с пунктом 12.6 документа "Дизайн кода для спека #6522" признаком того, что оплата была успешно проведена картой VISA, будет одновременное наличие не одного, а двух условий:

1.Значение"10"всоответствующейколонкесоответствующейстроки в базе данных.

2.Уменьшение баланса на счете с картой VISA на сумму, равную сумме оплаты.

То есть получается, что для тестирования одной вещи ("Оплата может быть произведена картой VISA") нужно проверить соответствие жизненной реальности двум ожидаемым результатам.

Унас есть два пути:

1.Разложить идею тест-кейса на две идеи и создать два тест-кейса.

2.Оставить идею тест-кейса неприкосновенной и включить в один тест-кейс два ОР, т.е. у нас складывается ситуация,