3. Тест-кейсы должны не повторять требования, а проверять их

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

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

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

Поясню на простых (естественно, выдуманных, чтобы читатели не краснели, при виде своих собственных творений) примерах.

Есть одно из функциональных требований к системе, для которого необходимо написать тест-кейсы: Значение в поле «Сумма» должно рассчитываться как сумма значений из полей «A» и «B».

Тест-кейс, написанный ленивым тестировщиком:

...

Действия:

Ввести значения в поля «A» и «B».

Ожидаемый результат:

Значение в поле «Сумма» должно рассчитываться как сумма значений из полей «А» и «B». (Иногда еще также в графе с ожидаемым результатом встречаются такие «шедевры» как: См. в ТЗ, в соответствии с ТЗ, наблюдаем ожидаемые значения и т.п.).

...

Тест-кейс, написанный неленивым тестировщиком:

...

Действия:

1. В поле «А» ввести значение 2

2. В поле «B» ввести значение 3

3. Нажать на кнопку «Рассчитать»

Ожидаемый результат:

В поле «Сумма» отобразилось значение 5

...

Чем второй тест-кейс лучше первого?

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

Далее, если речь идет о приемочных тест-кейсах, которые должны обязательно выполнить разработчики перед тем, чтобы передать версию на тестирование, то здесь в случае с первым тест-кейсом вообще все плохо. Т.е. реакция разработчика на такой тест-кейс такова (сужу по своему собственному опыту): «Я же и так все делал по требованиям, поэтому должно все работать, как я и сделал. Тем более я когда-то проверял, что 2 + 2 = 4». И разработчик со спокойной совестью ставит Pass и переходит к следующему тест-кейсу (который наверняка будет таким же неоднозначным :)).

Приведенный пример с суммированием, конечно же, очень примитивен для простоты понимания, но на практике часто приходится сталкиваться с тем, что менее очевидные вещи, чем A + B, описываются в тест-кейсах аналогичным образом и не приносят ожидаемого результата, т.е. проверки какого — либо требования. И в силу этого, после выкладки тестовой версии кажущиеся на первый взгляд очевидными (позитивные) тесты проваливаются.

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