Все больше и больше компаний переходят на гибкие (Agile) методы разработки программного обеспечения (ПО). Но методология Agile приносит с собой новый ряд сложностей. Среди них автоматизация функционального тестирования: в сообществе Agile мнения о полезности автоматизированного тестирования расходятся. Однако реальность такова, что группы разработчиков ПО должны управлять качеством, если они должны избегать операционных рисков. Организации поощряются во внедрении процессов Agile, которые подходят для их уникальных требований. Ничто, относящееся к Agile, не является предопределенным или обязательным. Поэтому нет ничего удивительного, что организации находят проблематичным внедрение методологии Agile в качестве надежного бизнес-процесса. Использование процесса создания ПО на базе методологии Agile - это еще одна переменная, которая усложняет решения, которые они должны принимать.
Автоматизация и создание ПО по методологии Agile
В мире методологии создания ПО Agile требования выдвигаются, меняются и перемещаются в списке приоритетов гораздо быстрее. В то же время создаваемая функциональность должна быть полностью протестирована, чтобы гарантировать ее соответствие требованиям конечных пользователей и бизнеса. По мере увеличения объема и сложности ПО становится ясным, что ручные процессы не смогут обеспечить быстрое получение воспроизводимых результатов. Это усиливает необходимость внедрения Agile. Без автоматизации качество неизбежно страдает, поскольку тестирование исключается из процесса с целью своевременного создания ПО.
Независимо от того, рассматривает ли ваш коллектив разработчиков переход на Agile, находится в процессе перехода или уже работает по этой методологии, важно продумать, как технология может поддерживать этот новый способ работы - особенно в области тестирования. Согласно исследованию компании Forrester, "в гибких (agile) процессах есть место для улучшения - например, с помощью улучшения поддержки методологии Agile со стороны основных инструментов для автоматизации тестов, управления тестами и управления требованиями". Forrester замечает, что в процессах Agile тестирование является непрерывным и обязательным, поскольку возможности не считаются "готовыми" до тех пор, пока не пройдут все связанные с ними контрольные примеры. Более того: "Из-за регрессионной нагрузки тестирование должно быть максимально автоматизированным (и обоснованным)". Организации, внедряющие Agile, сталкиваются со следующими проблемами.
- Одновременное использование Agile и традиционных методов тестирования.
- Определение средств, которые обладают гибкостью и пригодны для использования.
- Обеспечение возможности для активного внесения своего вклада для тех участников групп, которые не является техническими специалистами и специалистами по тестированию.
- Обеспечение интеграции со средствами с открытым исходным кодом.
- Обеспечение разработки на базе моделей или тестов.
Роль автоматизированного тестирования в разработке по методологии Agile
Давайте выясним, почему в среде разработки Agile нужно автоматизировать тестирование. Люди, которые вовлечены в тестирование, являются частью группы создания ПО. Это не изолированная группа, которой разработчики передают код на последнем этапе перед выпуском продукта. В идеале они сидят рядом с разработчиками, которые по мере создания кода на ранних этапах процесса передают его специалистам по тестированию для оценки соответствия критериям пригодности. Поскольку возможности создаются постепенно, а группе нужно поддерживать скорость, части кода нужно проверять быстро. Для достижения настоящего успеха в Agile функциональное тестирование должно быть быстрым, итеративным и гибким.
В частности, автоматизированное функциональное тестирование предлагает целый ряд эффективных возможностей, которые нельзя получить при ручном тестировании. Вот, например, некоторые возможности.
- Значительное ускорение процесса создания кода и тестирования с помощью поддержки быстрых и автоматизированных сценариев тестирования.
- Гарантия воспроизводимости тестов для обеспечения регрессионного тестирования между спринтами и итерациями.
- Дальнейшее повышение эффективности тестов с помощью надежных и гибких процессов управления тестированием.
- Исключение унаследованных неточностей, которые ручная работа вносит в процесс - в частности, когда время ограничено.
Необходимость скорости: ускорение процесса создания кода и тестирования с помощью быстрых и автоматизированных сценариев тестирования
Автоматизация позволяет специалистам по тестированию создавать простые сценарии для многократного использования. Эти сценарии можно развертывать для экономии времени и улучшения унификации тестирования для сходных пожеланий пользователей (User Stories), баллов Story Points или требований в одном или нескольких проектах. Эти сценарии, разработанные на базе User Story для улучшения функциональных возможностей, можно быстро и многократно запускать, что обеспечивает разработку на основе тестов (Test Driven Development). Такой подход значительно снижает рабочую нагрузку на специалистов по тестированию и исключает необходимость "марафонов" по тестированию, проводимых поздними ночами и по выходным и способных измотать группу.
Необходимость повторяемости: выполнение тех же тестов и сценариев тестирования с правильными критериями пригодности
Регрессионное тестирование требует, чтобы: 1) вы выполняли те же тесты каждый раз при тестировании определенной части кода; 2) чтобы сценарий теста составлялся относительно критериев приемлемости для каждого соответствующего функционального требования User Story. При каждом изменении кода (или его расширения для включения новой возможности) нужно перезапускать все функциональные тесты для всех требований пользователей вплоть до последнего изменения. Это нужно, чтобы гарантировать отсутствие непреднамеренных последствий для других функций. (При разработке по методологии Agile регрессионное тестирование должно обычно выполняться в конце каждой итерации. В некоторых случаях это означает ежедневное выполнение.)
При ручном тестировании из-за человеческих ошибок, изменений и отсутствия целостного подхода воспроизводимости добиться почти невозможно. Люди просто не могут точно запомнить, какие тесты они выполняли для каждой части кода на протяжении последнего итерационного цикла - и даже одно упущение может вызвать проблемы в конечном варианте кода. Но при автоматизированном и воспроизводимом функциональном тестировании и регрессионном тестировании можно выполнять тесты единообразно каждый раз, когда это нужно.
Пример Borland: использование автоматизированного тестирования для поддержки создания ПО по методологии Agile
У компании Borland есть свой собственный опыт корпоративного перехода на Agile. Мы наблюдали важную роль, которую автоматизированное тестирование и централизованное управление тестами могут играть в обеспечении успешного перехода. Мы начали свой переход на подход Agile в 2006 году. У нас было 350 инженеров, работавших над широким спектром проектов по разработке ПО в 13 различных офисах по всему миру.
В переходе на Agile мы следовали итерационному подходу, осуществляя переход в одном определенном географическом регионе, а не во всех сразу. Примерно более 60% групп разработчиков в Borland теперь используют методики Agile. Все эти методики поддерживаются продуктами Borland ALM, и их преимущества огромны. Однако мы признаем наблюдение, сделанное компанией Forrester: переход на Agile может быть для организаций трудным из-за изменений, которые нужно сделать в следующих областях:
- организационная структура;
- роли и зоны ответственности;
- управление требованиями;
- тестирование;
- управление проектами и портфелем проектов.
По данным Forrester, большинство организаций не готовы включить в свои процессы непрерывное и итеративное тестирование, необходимое для поддержки разработки по методологии Agile. Более того, в исследованиях Forrester отмечается, что "в корпоративном контексте обычно нужно делать некоторые исключения для тестирования с особенно большими требованиями к ресурсам, например, для тестирования производительности, безопасности, удобства использования, приемлемости для пользователей и приемочное тестирование".3 [GG3]
Borland служит полезным примером для других организаций, которые пытаются определить наилучшую стратегию тестирования для использования в своих методиках Agile. В нашей собственной организации участники групп географически распределены. Но, как мы доказали, это не препятствует внедрению методов Agile в группах. Мы смогли реализовать разумный баланс между инструментарием и автоматизацией, который помог нашим группам Agile работать эффективно.
Отправная точка
В качестве примера: в нашем офисе разработки в Линце, Австрия, было три группы разработчиков, которые использовали традиционный "водопадный" (waterfall) подход для разработки решений для тестирования Borland SilkTest . После некоторого анализа мы решили, что в рамках нашего перехода на Agile для нескольких групп важнейшим компонентом будет автоматизация инструментальных средств.
Очевидно, переход был основан не только на простой возможности использования инструментов - как и для многих других групп, первый шаг заключался в определении новых ролей, например владельца продукта (Product Owner, PO). Основная ответственность PO заключается в содействии обмену данными между участниками процесса со стороны бизнеса и техническими специалистами и в дальнейшей передачи их требований к ПО и изменений в группы разработки и обеспечения качества. Это поддерживалось с помощью ежедневных совещаний (stand-up) с использованием соответствующих средств. Такой подход обеспечивал обмен информацией и совместную работу для ВСЕХ участников группы, независимо от их реального расположения.
Группа в Линце перешла на четырехнедельные итерации. Это позволило группам разработчиков сосредоточиться на меньших единицах работы - шаг вперед к Agile. Группа поддерживала User Stories в Borland CaliberRM и оценивала их пригодность для тестирования с помощью средств обеспечения качества. User Stories были привязаны к Borland SilkCentral Test Manager. Это позволяло группам обеспечения качества разрабатывать контрольные примеры и связанные с ними сценарии автоматизированного функционального тестирования в Borland SilkTest. Результатом стал улучшенный процесс совместной работы, который обеспечил создание высококачественных тестируемых требований (выраженных как User Stories). Теперь разработчики и специалисты по тестированию получили четкие требования и могли внедрить тестирование на более ранних стадиях процесса разработки. Это дало им возможность эффективно обеспечивать разработку на базе тестов и поддерживать отслеживание связей между User Stories, кодом, тестами и результатами.
Интеграция групп тестирования для создания полноценных коллективов по разработке ПО
После успешного внедрения процесса тестирования и инфраструктуры, которая улучшила наши усилия в области Agile, мы перенесли группу обеспечения качества в группы разработки продуктов. Участники группы обеспечения качества получили возможность самоорганизации в группах, занятых разработкой определенного продукта, используя соответствующие сценарии автоматизированного функционального тестирования. Слияние групп дало следующие результаты.
- Улучшение обмена информацией, поскольку группа смогла разрабатывать сценарии функционального тестирования параллельно с кодом, основанным на тех же требованиях и изменениях.
- Улучшение возможностей добиться соответствия критериям качества, поскольку теперь все стали отвечать за превентивное обеспечение качества.
- Улучшение охвата тестов с помощью объединения тестов и совместного использования библиотек тестов модулей (сценариев SilkTest, созданных разработчиками) и функциональных тестов (сценарии SilkTest, созданные специалистами по тестированию), что позволило предотвратить дублирование. Это сократило усилия, необходимые для разработки автоматизированных сценариев и гарантированного охвата кода и тестов.
- Устранение дефектов и проблем с качеством на ранних этапах, что привело к повышению скорости.
Для поддержания стандартов качества и помощи группам в обеспечении адекватности тестирования мы создали еще одну роль под названием "наставник по обеспечению качества" ("QA coach") - единый ресурс, который предоставляет опыт в области обеспечения качества для всех трех групп. Под руководством наставника по обеспечению качества (и с помощью SCTM для организации и планирования сценариев, а также с помощью StarTeam для их хранения и контроля их версий) люди смогли выполнять свои роли более эффективно, совместно используя и многократно применяя сценарии Borland SilkTest во всех группах.
Выбор правильных средств для автоматизации тестов
Мы доказали, что методология Agile эффективно масштабируется, когда она поддерживается правильным набором людей, процессов и инструментов. Хотя многие могут поспорить, что в Agile нет места автоматизации, реальности географического разделения, многочисленных групп и ограниченных ресурсов диктуют более прагматичный подход.
Автоматизированное функциональное тестирование и централизованное управление тестами играют жизненно важную роль в том, чтобы помочь группам разработчиков реализовать процесс создания ПО на базе Agile. Но основная масса организаций сегодня продолжает использовать ручные процессы, которые могут затруднить (если не сделать невозможной) реализацию и масштабирование методов Agile в компании. Ручное тестирование замедляет производство и подвержено ошибкам - оно не поддерживает многократное использование и не обеспечивает предсказуемой воспроизводимости.
С другой стороны, те компании, которые развернули средства автоматизированного тестирования в традиционных проектах, столкнулись с другими проблемами относительно разработки по методам Agile. Например, большинство продуктов для тестирования ПО заставляет компании работать определенным образом (например, использовать "водопадный" метод), а не использовать гибкий процесс, настроенный под определенную компанию.
В противоположность этому, благодаря своему непосредственному опыту перехода на Agile мы гарантируем, что продукты Borland Silk могут помочь внедрить и улучшить процесс создания ПО на базе Agile. Одновременно обеспечивается качество, сокращаются риски и снижаются затраты. Средства тестирования Borland используются в тысячах организаций по всему миру. Эти средства могут поддерживать любой процесс разработки - Agile или традиционный. Их можно настроить на поддержку предпочтительных процессов любой группы разработчиков. Эти средства также позволяют коллективам внедрять автоматизированное тестирование - быстрое, воспроизводимое и точное. А поскольку они являются частью интегрированного пакета средств для открытого управления жизненным циклом приложений (Application Lifecycle Management, ALM), который поддерживает тестирование на базе требований и управление качеством в жизненном цикле, группы разработчиков не работают в изоляции. У каждого в организации есть информация о процессе создания ПО на базе методик Agile, и каждый может соответствующим образом участвовать в этом процессе.
Например, Borland SilkTest широко используется для записи и воспроизведения действий в графическом интерфейсе пользователя в приложении. Возможности записи и воспроизведения помогают увеличить скорость, с которой можно генерировать тесты и запускать их в любой традиционной среде тестирования. Также существует мощная возможность ссылаться на те части приложения, где, возможно, еще нет пользовательского интерфейса; очень часто это учитывается в проектах разработки, более ориентированных на Agile. Одной из самых больших проблем, с которой сталкиваются проекты разработки на базе Agile, является то, что при быстрой разработке приложения также быстро меняется и использование любой автоматизации тестов. Сценарии, которые имеют дело с пользовательским интерфейсом в этих средах, очень быстро становятся неэффективными, поскольку объекты и даже структура на интерфейса меняются.
SilkTest помогает этим проектным группам двумя очень сходными путями. Во-первых, возможность в SilkTest прямого вызова библиотек DLL внутри сценария, минуя пользовательский интерфейс. Это позволяет группам закреплять точки автоматизации в более конкретных областях приложения. Второй способ - через среду SilkTest Silk4J, с помощью которой усилия по автоматизации могут также привязываться к низкоуровневым Java-частям архитектуры.
В любом случае SilkTest помогает группам, предоставляя им возможность работать с гораздо более стабильными уровнями архитектуры приложения, а не просто с пользовательским интерфейсом. Эти тесты также могут создавать заполняющие артефакты в соответствующих сценариях для тех элементов, на которые есть ссылка, но которые еще предстоит создать. После создания этих элементов логика автоматизации может заменить стабы, создавая полностью функциональные сценарии автоматизации.
Borland SilkTest для создания тестов
Продукт Borland SilkTest предоставляет мощные средства автоматизации функциональных и регрессионных тестов. Интуитивные возможности записи и воспроизведения действий в графическом интерфейсе пользователя, а также стабильные и удобные в использовании языки тестирования позволяют группам создавать функциональные и регрессионные тесты, которые не нарушатся из-за минимальных изменений в приложении. Этот программный продукт также облегчает для разработчиков выполнение частого, регулярного и автоматизированного регрессионного и функционального тестирования ПО.
Borland SilkCentral Test Manager для управления и синхронизации тестов
Borland SilkCentral Test Manager - это мощное средство для управления тестированием ПО. Оно создано по принципу "все включено" и встраивает качество и эффективность в процесс тестирования. Borland SilkCentral Test Manager интегрируется с другими инструментами и технологиями Borland, а также с инструментами сторонних производителей для управления жизненным циклом приложений. Эта интеграция гарантирует, что тестирование ПО становится управляемым процессом, который распространяется на весь жизненный цикл разработки ПО и помогает обеспечить соответствие приоритетов бизнеса и разработки.
SilkCentral Test Manager также упрощает верификационные тесты сборок, что важно для поддержки разработки по методологии Agile. Каждая группа нуждается в гарантии, что новый код, который они создают каждый день, не вызовет неожиданных проблем в других частях приложения. Эти тесты, как правило, можно выполнить за два часа для каждой сборки и для различных конфигураций, что позволяет скрам-группе создавать рабочее ПО в конце каждого дня.
Java в качестве языка сценариев (Java as a Scripting Language)
Borland продолжает разрабатывать инновационные подходы к поддержке методологии Agile. Например, в качестве языка сценариев для SilkTest* добавлен язык Java (функция Java as a Scripting Language). Такая возможность позволяет разработчикам и специалистам по тестированию создавать сценарии для SilkTest на привычном языке разработки - Java. Это обеспечивается через подключаемый модуль Eclipse, который позволяет генерировать сценарии и работать на том же языке, который используется для самой разработки. Сценарии создаются и запускаются с помощью функции Open Agent в SilkTest.
SilkTest и FitNesse
FitNesse предоставляет среду с открытым исходным кодом, которая позволяет специалистам по тестированию определять тесты на бизнес-уровне (в таблице), где действия связаны с ожидаемыми результатами. Затем FitNesse ставит выбранные действия и результаты в соответствие автоматизированным задачам в SilkTest. Благодаря возможности использования языка Java в качестве языка сценариев мы создаем библиотеки, которые ссылаются на объекты и функциональность, с учетом параметров, определенных в тесте. Аналогично мы разрабатываем процедуры верификации, как и совместно используемые классы, которые также можно использовать. Более того, с помощью Open Agent мы можем вызывать эти сценарии через функции вызова внешних средств из FitNesse. Что это дает нам в конечном итоге? Возможность для пользователей, которые не являются техническими специалистами, разрабатывать сценарии тестирования в веб-браузере или вики-среде (FitNesse). Затем эта среда будет использовать SilkTest без какой-либо дополнительной работы по созданию сценариев для тестового управления приложением и его проверки. Результаты собираются из файлов .RES, созданные в SilkTest, и вставляются в браузер FitNesse. *Поддержка и разработка продукта Borland Silk 4Test будет продолжена.