Написание тестовых случаев (Test Case Writing)

Введение

Подошло то время, когда от философствования по поводу тестирования(Обеспечение качества. Контроль качества. Тестирование и Необходимые и достаточные условия для проведения тестирования) надо спуститься на землю и поговорить о самых незначительных составляющих его, а именно о тестовых случаях (test cases).

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

Далее в статье я постараюсь обратить вас в свою веру и рассказать, какой подход использую при написании тестовых случаев.

Тестовый случай (Test Case)

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

Тестовый случай (Test Case) - это последовательность действий, по которой можно проверить соответствует ли тестируемая функция установленным требованиям.

Под последовательностью действий понимается структура вида:

Action > Expected Result > Test Result

Пример:

Action	Expected Result	Test Result(passed/failed/blocked)
Open page "login"	Login page is opened	Passed

Структура Тестовых Случаев (Test Case Structure)

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

Каждый тест кейс должен иметь 3 части:

PreConditions	Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description	Список действий переводящий систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions	Список действий, переводящий систему в первоначальное состояние (состояние до проведения теста - initial state)

Примечание: Post Conditions не является обязательной частью. Это скорее всего - правило хорошего тона: "намусорил - убери за собой". Это особенно актуально при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов.

Пример тест кейса:

do A1, verify B1

do A2, verify B2

do A3, verify B3

В приведенном примере конечная проверка - В3. Это значит, что именно она является ключевой. Значит, A1 и А2 - это действия приводящие систему в тестопригодное состояние. А В1 и В2 - условия того, что система находится в состоянии пригодном для тестирования. Таким образом имеем:

Action	Expected Result	Test Result (passed/failed/blocked)
PreConditions
do A1	verify B1
do A2	verify B2
Test Case Description
do A3	verify B3
PostConditions

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

Теперь ответим на вопрос: "Почему данное разбиение удобно использовать?"

Ответ: конечная проверка одна, т.е. в случае если тест провален (test failed) будет сразу ясно из-за чего. Т.к. если провальными окажутся проверки В1 и/или В2, то тест кейс будет заблокирован (test blocked), из-за того, что функцию не возможно привести в тестопригодное состояние (состояние пригодное для проведения тестирования), но это не значит, что тестируемая функция не работает.

Action	Expected Result	Test Result (passed/failed/blocked)
PreConditions
do A1	verify B1	passed
do A2	verify B2	failed
Test Case Description:
do A3	verify B3	blocked
PostConditions

Детализация описания тест кейсов (Test Case Details Elaboration)

Бытует много разных мнений об уровне детализации при написании тест кейсов, а также количестве проверок в одном тест кейсе. Все они по своему правильные. Мое мнение, что уровень детализации тест кейсов должен быть таков, чтобы обеспечивать разумное соотношение времени прохождения к тестовому покрытию. Т.е. до тех пор пока покрытие тестами определенного функционала не меняется, можно уменьшать детализацию тест кесов.

Пример тест кейса 1:

Проверка отображения страницы
Действие	Ожидаемый результат	Результат теста
Открыть страницу Логин	- Окно Логин открыто - Название окна - Логин - Логотип компании отображается в правом верхнем углу - На форме 2 поля - Имя и Пароль - Кнопка Логин доступна - Линк забыл пароль - доступен	...

Пример тест кейса 2:
Название: Проверка отображения страницы
Действие: Открыть страницу Логин
Проверка: Проверьте, что отображаемая страница соответствует странице на картинке 1 (и прилагаем скрипншот страницы Логин)

В примере 1 и 2 покрытие будет одинаковым, но вот время, которое потребуется для прохождения, будет разным. Мне кажется, что второй пример будет даже нагляднее.

Заключение

В заключении скажу, что для того, чтобы команда тестирования работала сплоченно и не отвлекалась по вопросам оформления тест кейсов, у всех должен быть один шаблон или подход к их написанию. То что предлагаю я - это структура: PreConditions, Test Case Description, PostConditions. И уже ваше личное право пользоваться тем, что предлагаю я или придумать свой велосипед.