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

Вряд ли, к сожалению, мне поможет 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) - проверка в базе). Ещё раз подчеркну, что нужно избегать зависимости тест кейсов, т.к. при "выпадении" одного может получится блокировка другого вследствии нарушения целостности ссылок сцелочная ссылочность. Так же важным параметром "хорошести" тест кейсов служит то, что их сможет выполнить другой человек - т.е. кто-то, кроме составителя.
Удалять выпавшие тест кейсы не рекомендуется несмотря на их независимость друг от друга, во-первых потому что ВНЕЗАПНО может оказаться, что удалять не нужно было, а во-вторых, он может понадобиться в качестве базы для создания нового. Савин рекомендует переносить удалённые тест кейсы в специальный раздел.

Форсаж

Ссылки для Selenium'а:
оглавление статей: http://automated-testing.info/knowledgebase/avtomatizaciya-funkcionalnogo-testirovaniya/selenium
список с общими компонентами и их описанием: http://automated-testing.info/knowledgebase/article/chto-takoe-selenium-i-s-chem-ego-edyat
Selenium Core: http://automated-testing.info/knowledgebase/article/selenium-core-obshchie-ponyatiya
расширение под IDE и комманды: http://automated-testing.info/knowledgebase/article/selenium-ide-flowcontrol-primery-ispolzovaniya

Тест план, тест дизайн, тест кейсы.

Поскольку возникла пищащая необходимость разложить в голове по полочкам эти понятия, постольку буду делать это здесь, да и в качестве вводной теорчасти это будет небесполезно, ящитаю. Итак, пункт первый.
Тест план. Как новичок обычно представляет себе процесс тестирования? Ну там посмотреть текстовые ошибки, отловить баги, понажимать кнопочки так и сяк. Баг репорт склепать и отправить разработчикам. Вот что я вам скажу - херня всё это, процесс собственно отлова багов занимает процентов 10-20 всего процесса (зато регрессионное тестирование это по стопиццот раз одно и тоже). Ибо нажимая так и сяк каждый раз одно и тоже, приходишь к выводу, что делаешь одну работу и нужно её как-то систематизировать, а потом просто адаптировать к каждому случаю. То есть нам нужен план отличный план!. Тест план Джеймс План. Итак, тест план - это документ, описывающий весь объём работ по тестированию (более полно тут, с обязательными пунктами) с учётом используемых подходов, системных ресурсов, человеческих в конце концов ресурсов (кто и что будет разрабатывать и тестировать). Я полагаю, тест план в идеале должен составлять руководитель отдела тестировщиков (Team Lead?), ибо плохо пока представляю иерархию в этой области. Но кто-то главный, кто видел процесс и изнутри, и снаружи - это точно.
Тест дизайн. Итак, тест план уже есть, задачи разделены, серьги розданы, можно кидаться к вожделенному отлову зловредных багов? Не-ет, родные, мы же не хотим из раза в раз на разных продуктах делать одно и тоже без системы, с ужасном накануне релиза вспоминая что забыли проверить ещё "вот это, это и то"? Мы-то хотим спать с чистой совестью, зная, что прошлись по всем возможным местам обитания любимых насекомых. Значит, каждому из команды нужен ещё и тест дизайн, на основе которого будут составлены тест кейсы, на основе которых будут писаться баг репорты в доме, который построил Джек, и на основе которых будет идти регрессионное тестирование (прогонка после отладки) и не один раз. Собственно, тест дизайн - это всего лишь набор техник для составления тест кейсов. В некотором роде у Тамре вот тут тоже техники тест дизайна. По protesting.ru это:
Эквивалентное Разделение (Equivalence Partitioning - EP)
Анализ Граничных Значений (Boundary Value Analysis - BVA)
Причина / Следствие (Cause/Effect - CE)
Предугадывание ошибки (Error Guessing - EG)
Исчерпывающее тестирование (Exhaustive Testing - ET)
То есть это приёмы, на основе которых мы будем писать тест кейсы. К примеру, Анализ граничных значений - это те самые граничные значение, +1 и -1, эта техника будет использована для валидации полей ввода данных. Если есть поля вводы данных - без этого не обойтись и мы уже не забудем включить этот метод в тест кейсы при проверке всех возможных полей ввода. Кстати, я не совсем понимаю почему бы, имея прямой контакт с разработчиками, заранее не оговорить, чтобы такие поля прописывались с некими стандартами - скажем, тип поля text с ограничением на ввод по ASCII (Юникод) и количеству символов? Ну, к примеру, в поле логин нельзя ввести больше 256 символов только из английской раскладки. На любое другое значение либо превышение размера поля возвращать сообщение об ошибке. Ну, это я так. В рамках тест дизайна. Что касается того, кто разрабатывает тест-дизайн, так это тест-аналитик (определяющий что тестировать) и тест-дизайнер (определяющий как тестировать).
Итак, техники тест дизайна мы изучили, можно приступать к разработке тест кейсов. Это, пожалуй, самая объемная часть работы, потому как, помимо составления, требует и документирования (первые две части тоже требуют документирования, просто эта - наиболее объемная). Тест кейс (тестовый случай) - это, если говорить по существу, условия, в которых система выдаёт ту или иную ошибку (или реагирует правильно). Как правило, условия создаются специально, но вот для текстовых ошибок не нужно что-либо создавать. Но вот указывая последовательность действий, которая приведет к окну с тестовой ошибкой, мы описываем Steps to reproduse - шаги воспроизведения ошибки- один из артефактов баг репорта. В тест кейсе это просто Action - действие, приведшее к фиксации бага. Два других артефакта тест кейса - это Result (результат фактический) и Expected Result (ожидаемый в идеале результат. Как обычно, тут более детально. Тест кейсы составляются непосредственно тестировщиком, хотя вот в России, по слухам с Дальнего Востока, они составляются старшим и даются для прохождения манки-тестеру.
Я хотела ещё зацепить такое понятие, как тестовое покрытие, но, видимо, уже в следующий раз, т.к. слишком много информации в одном посте и папа с малым уже нагулялись и требуют внимания :)
P.S. Ещё на эту же тему: та-дам очень хорророшая аналогия со строительством, настоятельно рекомендую.