четверг, 24 сентября 2009 г.

Правила написания тест кейсов

Как и предполагал в предыдущих постах, выкладываю эти нехитрые правила. Своим созданием они обусловлены были достаточно большой вероятностью появления в нашей организации тестировщиков с небольшим опытом, либо без такового вообще. Поэтому постарался адаптировать простые истины под нашу специфику:

1. у каждого тест кейса (ТС) уникальное имя и ID (Без этого никуда- ибо различать и не путать тест кейсы необходимо, а при наборе их в тестран такие вещи не исключение. Не забываем, что на один юз кейс может быть написано достаточно много очень похожих тест кейсов, но проверяющих совсем разные вещи или работающих в разных условиях. Необходимо их различать.) Напомню, что нумерацию тест кейсов я вводил на стадии формирования дерева юз кейсов. Делалось это примерно так: Уникальный номер тест кейса состоит из буквы (С- клиент(client), A -администратор (admin))и семи цифр. Если в указанном ниже номере присутствует менее семи цифр, необходимо добавить нужное количество нулей в конец номера. Например, тест кейс, где производится верификация количества попыток логина при неправильном пароле (первый в списке), имеет номер C1111100, второй C1112100:
1. Общие тесты приложения:
1.1 Логин:
1.1.1 Некорректный:
1.1.1.1 Некорректный пароль:
1.1.1.1.1 Количество попыток;
1.1.1.2 Корректный пароль:
1.1.1.2.1 Количество попыток;
В моем случае основной состав дерева был уже сформирован, когда пришло время браться за нумерацию. Поэтому прикинуть необходимое количество цифр для номера труда не составило. Однако необходимо помнить о вероятных перестановках структуры дерева и практически 99%ных добавлениях новых тест кейсов, и предусмотреть возможные перекомбинации номеров.

2. Должен быть указан приоритет ТС (поговорим отдельно), цель (цель проверки- что именно проверяем), источник информации(спек, список требований (ссылки на требования в системе управления требованиями), и т.д.), категория (например, функциональный, юзабилити, стресс и др.), тип (ручной, автоматический), версия.

3. Предустановки- обязательны. (как правило, каждый ТС должен быть доступен для выполнения как в составе съюта, так и в составе произвольного набора ТС; так и в отдельности от других ТС). Соответственно должны (могут) быть описаны действия по завершению ТС, но не входящие в его тело- "постустановки" (особенно для автоматизированного тестирования).

4. Версия ТС- обязательна для заполнения и отслеживания. Формируется от "0.01". Версии изменения самих шагов (непринципиальные): +0.01. Версии изменения последовательности шагов (наряду с изменениями внутри некоторых шагов): +0.1 (с округлением: 0.14->0.20).Версии глобальных изменений (или крупных и многочисленных изменений в соответствии с предыдущим вариантом) +1.00 (1.23->2.00).

5.нумерация шагов- по порядку. Без комментариев :)

6. Действие (Action)- конкретное описание конкретного действия (необходимо предусматривать возможность разностороннего получения одного и того же результата (в минимальных отступлениях, например, контекстное меню и выбор меню из тулбара), и предоставлять выбор при выполнении ТС. Для более полного охвата функционала от итерации к итерации тестирования.) Необходимо помнить, что чрезмерный разброс действий- крайне недопустим. Так же необходимо учитывать то обстоятельство, что по ручным ТС пишутся автоматические скрипты (TS). Поэтому необходимо учитывать инвариантность выполнения ТС скриптом. (То есть если в некотором скрипте была описана последовательность действий через, например, контекстное меню, то- в другом логично реализовать это через вызов меню из тулбара, и наоборот.). В отдельных случаях (например, при тестировании в ТС конкретно вызова функции\метода из меню тулбара) должна быть описана именно эта последовательность действий и никакая другая. Так же это должно быть отражено в названии и, главное, в цели самого ТС.

7. Ожидаемый результат (Result)- конкретное описание состояния приложения или конкрентой его части. должно включать в себя не только описание текущего объекта(ов), но и окружающую среду. Например, при тестировании ввода текста в ворде должно быть описано не только то, что текст введен, но и то, что он имеет стандартный формат, не выделен, не курсив и т.д., а также, что ворд имеет стандартный вид (отображены стандартные кнопки\панели, и не имеет "специальных" "отклонений", которые могут быть вызваны дополнительными действиями пользователи или машины).

8. В Любом корректном ТС должно быть не более 10-12 шагов. Отдельные исключительные случаи оговариваются отдельно.

9. При написании ТС необходимо руководствовавться всей доступной информацией для отражения последних (и возможных!) изменений приложения. Необходимо закладывать на будущее вероятность изменений приложения и заранее обдумывать принцип построения ТС для последующей модификации (если таковая понадобиться) при наименьших временных и ресурсных затратах.

10. Шаги в ТС должны быть описаны четко и понятно даже для неподготовленного человека, но тем не менее должны быть описаны в соответствии с принятым глоссарием, который формируется параллельно. При принятии решений о переименовании того или иного объекта или действия все ТС должны быть модифицированы централизованно.

11. Модификация ТС осуществляется централизовано и только при необходимости внесения критичных изменений. (нет необходимости перебирать все ТС ради изменения названия кнопки). Некритичные изменения должны накапливаться, хранится в общем доступе и отслеживаться. Количество накапливаемых изменений ограничено и должно быть регулярно согласовано.

12. Поиск шагов(слов, действий) в ТС должен осуществляться автоматическими средствами поиска (например, ctrl+F). Здесь есть, конечно, некая зависимость от среды, где хранятся ТС.

13. При нахождении нужного места(шага) необходимо убедиться в его неактуальности и потребности изменений. (так как в ТС могут быть описаны специфические вызовы функций (например, вызов старого функционала)).

14. Недопустим Copy\Paste и последующее сохранение ТС (при создании нового или модификации существующего ТС). Допустим вариант: создание, Copy\Paste, внесение изменений в атрибуты ТС (номер, название, цель, и тд), внесение изменений в тело ТС, и только потом сохранение. Хотя выгоднее писать каждый ТС с нуля, все мы помним о времени.

15. Все ТС должны быть структурированы и сгруппированы по тестируемому функционалу.

16. Допускается создание необходимого количества съютов, для регрессионного тестирования. Вопрос должен обсуждаться индивидуально для каждого случая. Помня о времени, затрачиваемом на разработку вообще и на тестирование в частности, правильнее будет собрать набор только из ТС, которые необходимо протестировать, а не из всех подряд.

17. ТС должны писаться в соответствии с расстановкой приоритетов- в начале должны быть описаны ТС "приемочного" типа. Таким образом будет производится дымовое тестирование приложения. Нет смысла тестировать неработоспособное приложение. Затем пишутся ТС, покрывающие основной функционал приложения и другие.

18. Все баги, дефекты, недочеты должны быть сколлекционированы (баги в систему багтрекинга, по недочетам, неточностям- отсылка писем, сообщений, вопросов). ТС должен быть написан, даже если существует баг, непозволяющий его выполнить на данный момент. При этом в ТС ставится пометка, что он bloked by #### (номер бага) и незакончен для редактирования(в системе багтрекинга этому багу проставляются номера ТС, на которые он влияет, чтобы после фикса бага не искать их; теем не менее должен быть проведен автоматический поиск по ТС, так как на момент постинга бага в систему окончательно не известно- все ли ТС тестирующие эту область написаны.Могут быть написаны новые ТС.). Как только баг пофиксен- ТС должен быть закончен и включен в исполняемые съюты.

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

20. Все существенные изменения должны быть задокументированиы автором изменений и хранится в связке с каждым ТС, который был модифицирован. То есть должны быть: дата , автор, характер изменений (или сами изменения). Можно взять за основу комментарий к чекину, но чекинить за один раз придется по одному модифицированному ТС.

21. Все ТС должны быть в актуальном состоянии. Допускается "запаздывание" актуализации при неясном окончательном функционале. Не допускается начало работ по актуализации ТС при неясном окончательном функционале. Никому не нужна лишняя бесполезная работа.

22. Все баги должны быть покрыты ТС-ами. Все требования должны быть покрыты ТС-ами. Весь описанный функционал должен быть покрыт ТС-ами. В идеале :)

23. Все результаты выполнения тестирования должны хранится в системе учета и хранения результатов. Или в любом доступном, подходящем месте.

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

25. Сначала должны быть описаны положительные ТС, потом отрицательные. Допускается одновременное внесение в план обоих типов ТС.

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