Конспект Савина

Вряд ли, к сожалению, мне поможет Selenium - по крайней мере IDE не записывает действия во флеше.
И как бы я не не любила Савина, читать придётся. Ибо эбо.
Итак, тест кейсы по Савину. Я уж не буду снисходить до уровня детсада как это делает Савин и пудрить мозги тупыми конкретными примерами, воспользуюсь определением с простестниг'а: Тест-кейс (тестовый случай) - это прописанная совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. В виде таблицы представляется полями Действие (Action), Ожидаемый Результат (Expected Result) и Фактический Результат (Result). На практике (моей) используется поле с фактическим результатом, а отметку о том пройден тест кейс или провален ставят в чек-листе (check list). Так же необходимыми атрибутами тест кейса являются поля с предусловием (состояние системы на начало выполнения тест кейса, по Савину "SETUP and ADDITIONAL INFO"), кратким описанием (summary или IDEA по Савину) и уникальным номером - ID. Так же в тест кейсе может быть указан его приоритет (по Савину), однако чаще всего приоритет фигурирует в баг репорте (Bag Report) - отчёте о найденом баге (проваленном тест кейсе). О нём я ещё буду писать. Так же Савин предлагает вести историю изменений тест кейсов (я бы уточнила - тест сьюитов (test suite) как комплекта тест кейсов), это кажется разумным. В целом, я бы оформляла тест кейсы примерно так. На первой - краткие описания с ID, на отдельных страницах - сами кейсы со всеми атрибутами. Бывает, если кейсы оформлены в док документе, приходится часто листать туда-сюда для того, чтобы найти нужный, для этого лучше реализовать список с кратким описанием и удобной навигацией по сьюиту.
Тест кейс считается пройденным (passed), если ожидаемый результат совпадает с фактическим. Соответственно, проваленным (failed), если фактический результат оказался отличным от ожидаемого. Так же у тест кейса может быть состояние заблокирован (blocked), оно возникает если невозможно выполнить какое-либо условие из Действия (Action).
У Савина так же описан такой функционал, как поддерживаемость тест кейсов. Поскольку мы тест кейсы пишем не для одного раза и планируем ими пользоваться регулярно, а в программе может что-то меняться, нужно максимально продумать их дальнейшее сопровождение. Для этого тест кейсы должны быть: a) максимально независимы друг от друга и b) минимально конкретизированы - т.е. мы должны избегать отсылки к конкретным полям/товарам/атрибутам, поскольку они могут меняться с течением времени. Пример: в "добавьте товар "мишка плюшевый" в корзину" следует опустить имя товара, т.к. мишки на складе могут закончится и воспроизвести тестовый случай будет невозможно. Я считаю это разумно, но слишком общее описание будет занимать больше времени на разбор содержания, поэтому тут нужно найти золоту середину - и чтобы избежать излишней детализации, и чтобы не удариться в пространные описания.
Так же Савин уточняет, что ОР (ожидаемых результатов) в одном тест кейсе может быть и два. К примеру, если мы проверяем функционал добавления товара в корзину и смотрим, чтобы он корректно отобразился в корзине и одновременно в базе данных (т.н. "проверка внутри" (front end) - проверка интерфейса пользователя и "проверка изнутри" (back end) - проверка в базе). Ещё раз подчеркну, что нужно избегать зависимости тест кейсов, т.к. при "выпадении" одного может получится блокировка другого вследствии нарушения целостности ссылок сцелочная ссылочность. Так же важным параметром "хорошести" тест кейсов служит то, что их сможет выполнить другой человек - т.е. кто-то, кроме составителя.
Удалять выпавшие тест кейсы не рекомендуется несмотря на их независимость друг от друга, во-первых потому что ВНЕЗАПНО может оказаться, что удалять не нужно было, а во-вторых, он может понадобиться в качестве базы для создания нового. Савин рекомендует переносить удалённые тест кейсы в специальный раздел.