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

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

Зачастую, когда объем автотестов становится весьма большим, достаточно тяжело уделять внимание запускам тестов. Тесты выполняются долго, часть проблем выявляется только после серии прогонов тестов и т.д. Более того, весьма полезно, чтобы результаты приходили регулярно и изменения, внесенные в код подхватывались по мере их внесения. Да и по сути, запуск тестов - это очередная рутина, которую хорошо бы делать регулярно, но в итоге всё делается, как получится. Соответственно, надо бы это как-то автоматизировать. Тут как раз подходит практика "Чёртового колеса"

Что это такое? Да, по сути это запуск всех тестов в бесконечном цикле. Вот и всё. Но сама по себе идея, как и многие другие идеи, весьма проста в озвучивании. Реализация же требует некоторой возни. Вот сосредоточимся на этом.

Итак, для того, чтобы можно было запускать тесты в бесконечном цикле нужна как минимум возможность одного запуска, после которого без всяких дополнительных действий можно повторить запуск полностью идентичным путем, после чего состояние системы останется таким же, как и до запуска. Что имеется в виду? Например, если мы используем какой-то внешний инструмент для тестирования (для того же UI-level тестирования как правило используются отдельные приложения), то получается следующая ситуация:

1. До начала запуска необходимо гарантировать, что средство тестирования запущено
2. По завершении запуска желательно средство тестирования закрыть по ряду причин

Всё это очевидно и решаемо. Наиболее простой случай - это использование определенных опций командной строки для закрытия средства тестирования после завершения выполнения всех тестов. Как правило средства автотестирования подобную опцию предоставляют. В крайнем случае в командных процессорах операционной системы есть команда удаления процесса по определенному имени.

Теперь ключевой момент: как зациклить.

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

• Все тесты (или большинство) начинаются с некоторого фиксированного состояния - это соответствует пользовательскому сценарию по работе с некоторой системой. Зачастую, есть общий набор действий, от которого уже потом отталкивается тест. С точки зрения автоматической реализации, будет написан некоторый метод или другой вид модуля, который приводит систему в исходное состояние и потом возвращает в него (если надо). Во многих решениях автоматизации подобная реализация предусмотрена специальными блоками (setUp, tearDown в JUnit-e, appstate в СилкТесте и т.п.).
• Тесты не зависят друг от друга - это очень болезненный момент. Нехорошо, когда сбой в одном из тестов повлечет за собой ошибки в других тестах. В этом случае непонятна сегментация тестов. Фактически, получаем один длинный workflow-тест, который разбит просто на подпункты и сбой в одном месте влечет за собой "эффект домино". Чтобы избежать подобного эффекта, лучше сразу предусмотреть возможность выполнения теста как в пакете, так и отдельно. Подобное выравнивание достигается фиксацией начального состояния (см. предыдущий пункт), а также определением дополнительных условий, необходимых именно для данного теста. Зачастую, эта проблема соприкасается с проблемой организации внешних данных для тестов.
• Одна функция - один тест - идея заключается в том, чтобы тесты делать не огромными, которые бы охватывали множество разных аспектов или какой-то длинный workflow, а более-менее сосредотачивались на некоторой одной функции. То есть, тест строится на том, что мы перешли в некоторое состояние, из которого доступна тестируемая функция, сделали ввод и проверили результаты заботы функции, а затем вышли. Не больше, не меньше. Если уже затрагивается более одного бизнес-функционала в одном тесте, при этом эти функции не являются взаимо-зависимыми, то в результате наши автоматизированные тесты рискуют пропустить ошибку в одном функционале, если будет выявлена критичная ошибка в другом функционале, который проверялся раньше. С точки зрения дизайна разница в предложенных подходах незначительная, но с точки зрения реализации появляются проблемы с выравниванием состояния приложения, чтобы можно было продолжить тест. Безусловно, глупо плодить тысячи мелких и крайне похожих тестов, но и слишком длинные сценарии вредны. Нужно искать некоторый баланс, удобный и для дизайна и для реализации
• Имеется фиксированный набор выполняемых команд и верификаций - имеется ввиду, что было бы неплохо сформировать достаточно узкий и в то же время покрывающий по максимуму набор выполняемых команд с поправкой на параметры. Например, если мы тестируем Content Management System, то у нас для разного типа содержимого есть фиксированный набор операций: перейти - создать и заполнить - сохранить и проверить - переоткрыть - модифицировать - сохранить и проверить. Вот по такому шаблону можно пройтись по всем типам содержимого, специфику составляют только используемые ресурсы. В этом случае, тест-дизайнер делает много дублирований, которые потом устраняются во время автоматизации, а ведь настоящий джедай знает, что Copy/Paste sucks. Более того, есть различные подходы в автоматизации тестирования, которые эффективны именно при определенном дизайне. Так вот тот же keyword-driven подход как раз наиболее эффективен, когда можно выделить фиксированный набор действий. Поэтому, формирование единого каркаса для группы тестов, резко уменьшает работу тест-дизайнеру, а затем и автоматизатору