вторник, 12 февраля 2008 г.

Написание тестовых случаев (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. И уже ваше личное право пользоваться тем, что предлагаю я или придумать свой велосипед.

5 комментариев:

Анонимный комментирует...

Дополнить основу Action > Expected Result > Test Result можно так:

Abstract (Case Description) > Action (я это называл "Steps to reproduce" > Expected results > Actual result > Comments

Анонимный комментирует...

"Steps to reproduce" (шаги воспроизведения) чего?
STR более соответсвуют Багу, а не тестовому случаю (ИМХО).
В крайнем случае можна заменить на Action steps. Хотя Action более лаконично :)

А.Б. комментирует...

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

Я своим постом лишь расписал основу (костяк) тест кейса, с которой рекомендовал бы начать. А вот во что ее заворачивать, и как расширять - это уже тема другой статьи.

Анонимный комментирует...

Коллеги, с точки зрения чистоты теории - да, в тест-кейсе STR не пишут. Но я практик, и я начал так писать просто потому, что эти два термина тождественны.

Если я провожу тест строго по скрипту, и нахожу дефект, то в трекер я просто копирую эти самые STR, они же Action, они же "былина о том, что и как нажималось, да и что из этого получилось".

Анонимный комментирует...

спасибо!! как раз то что нужн...точно и по сути...без лишних отклонений от темы и ненужных усложнений

Условия копирования публикаций:

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