Мы подготовили перевод статьи Ганса Бувалды, технического директора компании LogiGear, в которой он развеивает мифы и опасения, связанные с автоматизацией тестирования в проектах Agile.

Ганс Бувалда (Hans Buwalda) за свою профессиональную карьеру приобрел огромный опыт работы в качестве разработчика ПО, менеджера и главного консультанта в ведущих компаниях и организациях в разных странах мира. Предложенные им методы тестирования (на основе действий и в стиле мыльной оперы) помогли многим заказчикам разработать масштабируемые и легко поддерживаемые решения для большого объема сложных задач по тестированию. Ганс часто выступает в качестве докладчика на международных конференциях. Также он является соавтором книги Integrated Test Design and Automation.


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

• необходимы хорошо спланированные и организованные процессы проектирования тестов и автоматизации;
• эти процессы проектирования и автоматизации должны быть организованы на основе отдельных жизненных циклов.

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

Тестирование на основе действий

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

1. Не один, а три жизненных цикла

Обычно задачи по тестированию и автоматизации включаются в жизненный цикл разработки системы независимо от того, какой подход используется — каскадный или Agile. Однако в ABT выделяется три жизненных цикла, которые хоть и взаимозависимы, но в проектах ABT планируются и управляются как отдельные сущности:

1. Разработка системы: осуществляется в соответствии с любой традиционной или гибкой моделью жизненного цикла разработки системы;
2. Разработка тестов – включает в себя проектирование тестов, выполнение тестов, анализ результатов тестирования и сопровождение тестов;
3. Автоматизация – основное внимание уделяется ключевым словам действий, интерпретации действий, сопоставлению пользовательских и других интерфейсов, исследованию технологических проблем и т. д.

2. Проектирование тестов

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

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

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

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

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

3. Автоматизация

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

В ABT инженеры по автоматизации занимаются автоматизацией действий и созданием «определений интерфейсов» для управления взаимодействием тестируемой системы с различными интерфейсами (пользовательскими и другими). Для выполнения этих задач автоматизации требуются специальные навыки и опыт работы.

Гибкая разработка тестов

При использовании ABT с двумя отдельными жизненными циклами — разработки тестов и автоматизации тестирования — следует обратить внимание на две темы, которые важны для включения автоматизированного тестирования в проекты Agile:

1. Проектирование и разработка тестов;
2. Автоматизация.

При использовании методологии Scrum со спринтами тестирование в проектах Agile разделяется на три процесса:

1. Тестирование в регулярных спринтах разработки системы;
2. Разработка тестов до спринтов разработки;
3. Тестирование после завершения разработки.

1. Тестирование в регулярных спринтах

Самая распространенная практика — это разработка и выполнение тестов в рамках спринтов. В спринте функциональность определяется на основании беседы с заказчиком и историй пользователей для выявления того, что именно необходимо тестировать. Тестирование может осуществляться посредством разработанных тестов, аналогичных тестовым модулям ABT, а также посредством исследовательского и интерактивного тестирования. Кроме того, будет очень полезно провести хотя бы некоторые наиболее «интересные» интерактивные тесты в тестовых модулях для последующего использования.

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

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

2. Разработка тестов до спринтов разработки

При применении метода ABT использование действий, в частности, бизнес-действий высокого уровня, позволяет разрабатывать тесты, ориентированные не на технические аспекты, а на бизнес-функции. Такие тесты обычно называют тестами высокого уровня. Они не касаются элементов пользовательского интерфейса, а направлены на бизнес-транзакции, например, оформление запроса на ипотечный кредит или аренду автомобиля.

Тесты более высокого уровня могут быть разработаны на начальной стадии проекта. Для их разработки не нужно ждать завершения спринта разработки системы, так как в этом случае остается мало времени на определение бизнес-функций и создание подходящих тестов для их проверки.

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

• Количество тестов бизнес-уровня должно быть максимально большим, так как они обеспечивают общее качество продукта и не зависят от изменений системы, которые не затрагивают тестируемые функции.
• Необходимо использовать этап проектирования тестов высокого уровня в ABT (где выделяются тестовые модули), чтобы определить, какие функции можно проверить в первую очередь при проведении тестов бизнес-уровня и какие потребности можно закрыть в детальных тестах в рамках спринтов разработки.

3. Тестирование после спринтов

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

На мой взгляд, такое «последующее тестирование» является основной областью, в которой целесообразно иметь заранее разработанные тестовые модули и полностью автоматизированные действия. Это позволит сэкономить ценное время, особенно когда приближаются сроки выпуска продукта.

Гибкая автоматизация тестирования

Для описания автоматизации тестирования в проектах Agile, как правило, используется понятие «своевременная автоматизация». При применении метода ABT это понятие меняется и звучит как «своевременная разработка тестов». В любом случае автоматизация высокого уровня играет важную роль в повышении производительности и ускорении спринтов.

Чтобы быстро и своевременно обеспечить автоматизацию, следует соблюдать следующие правила:

• Создание основы на начальном этапе;
• Повышение надежности автоматизации;
• Обеспечение тестируемости тестируемой системы;
• Тестирование автоматизации.

1. Создание основы на начальном этапе

Успешная автоматизация начинается с создания надежной основы для разработки последующих действий. Такая основа должна обеспечивать различные возможности: выполнение всех необходимых операций на всех классах пользовательских интерфейсов, доступ к интерфейсам API, возможность выполнения запросов к базам данных, компилирование и обработку сообщений при использовании соответствующих протоколов и т. д.

Хотя многие технические возможности доступны при использовании созданного компанией LogiGear инструмента TestArchitect, большинство наших проектов начинаются с исследований и разработок, связанных с конкретными техническими проблемами заказчика, например, моделирования устройств для кассовых терминалов, работы с трехмерной графикой для нефтеразведки, тестирования мобильных устройств, доступа к встроенному ПО в диагностическом оборудовании и т. д.

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

2. Повышение надежности автоматизации

Суть проектов Agile в том, что многие элементы тестируемой системы проясняются только тогда, когда они реализуются в программе в рамках итераций, таких как спринты в Scrum. Это прежде всего относится к областям, в которых особенно важна автоматизация, например, при тестировании пользовательского интерфейса. Эти элементы могут претерпевать множество изменений в процессе разработки. При этом автоматизация не должна становиться «узким местом». В этом случае главное — это гибкость.

Модель тестирования на основе действий способна обеспечить необходимую гибкость, поскольку она позволяет скрыть детали в отдельных действиях, которые потом при необходимости можно быстро перенастроить. Однако необходимо учитывать и другие моменты. Чаще всего в наших проектах возникает проблема «тайминга» (“timing”). Нередко для выполнения автоматизированных действий приходится ждать, когда тестируемая система отреагирует на то или иное действие и будет готова для выполнения следующего.

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

3. Обеспечение тестируемости тестируемой системы

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

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

Если эти значения определены на ранних стадиях проекта, то с помощью, например, такого инструмента, как TestArchitect, можно создавать «определения интерфейса» и использовать их еще до построения тестируемой системы.

Примеры таких полезных свойств — атрибут «id» в элементах HTML, «name» в Java/Swing и «accessibility name» в .Net и WPF. Они никак не влияют на пользовательский опыт, но доступны для инструментов автоматизации. Кроме того, использование таких свойств помогает решать проблемы локализации: кнопку «OK» всегда можно найти, даже если надпись на ней будет на другом языке.

4. Тестирование автоматизации

Автоматизация должна быть протестирована. В ABT это означает, что необходимо протестировать действия и определения интерфейсов. Они представляют собой своего рода продукт, который инженеры по автоматизации предоставляют тестировщикам, этот продукт должен быть высококачественным. Необходимо в каждом проекте иметь как минимум одну папку (в дереве тестов TestArchitect) с тестовыми модулями, предназначенными для тестирования действий и определений интерфейсов, а не самой тестируемой системы.

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

22 ноября Ганс Бувалда приезжает в Москву с мастер-классом "Пять ключевых факторов успешной автоматизации тестирования".

Больше статей от Ганса Бувалды можно найти здесь.