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

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

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

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

Важность управления сценариями тестирования

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

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

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

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

Первичные категории тестирования

Вторичные категории тестирования

ALM помогает оптимизировать вашу работу

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

В отдельной организационной ячейке (silo) команда тестирования может достаточно хорошо выполнить тестирование отдельной функции. Но распространите эту ячейку на всё остальное - и внезапно менеджменту станет проще. У него будет актуальная информация о статусе тестирования, необходимая для решений плана «выпускаем/не выпускаем». Имея актуальную, живую обратную связь, ведущую к данному решению, менеджмент может принять меры, чтобы предотвратить ситуацию отказа. По моему опыту, все функции ALM улучшаются, если информация о тестировании постоянно доступна.

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

Важность управления требованиями

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

Управление сборками и релизами

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

Обычно требования со временем меняются, и набор тестов должен меняться соответственно, пока ПО в стадии тестирования. Управление версиями используется, чтобы убедиться, что и требования, и сценарии тестирования, и ПО нужным образом пересмотрены, чтобы можно было протестировать сборку, ведущую к релизу. Чаще всего сценарии тестирования просто добавляются в конфигурации и удаляются из них. Но существуют и более сложные тесты, которые требуют контроля версий и изменений, потому что сами тесты подразумевают развитие. Возможность такого контроля версий и изменений уже предоставляется современными инструментами ALM для ПО и его требований.

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

Непрерывная интеграция требует определенного уровня автоматического тестирования. Функции сборки и тестирования в инструменте ALM могут помочь убедиться, что продуктивное тестирование выполнено автоматически для каждой системной сборки. Это требует проверки правильности настройки данных среды до запуска автоматического теста (и это не должно занимать слишком много времени).

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

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

Необходимый элемент - отслеживание проблем

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

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

Инструмент ALM должен также поддерживать такие запросы, как «Когда была решена проблема?», «Сохранилась ли проблема в такой-то сборке?» - и так далее. В идеале успешный запуск сценария тестирования должен автоматически переводить проблему в статус решенной.

Как отслеживание функций и управление проектом соотносится с ALM

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

Процент успеха может возвращаться в инструмент ALM, чтобы помочь установить фактический уровень готовности тестируемого блока, как минимум с функциональной стороны. Схожим образом набор тестов «белый ящик» происходит из документации по дизайну, что помогает протестировать дизайн API, модуля и даже подсистемы. Похожие техники могут быть использованы для оценки уровня завершенности дизайна. Данная обратная связь помогает улучшить точность управления проектом.

Если руководитель проекта спрашивает неопытного разработчика о статусе завершенности задачи, то ответ будет примерно таким: «80% сделано, еще 20% осталось». По моему опыту, эти последние 20% отнимают куда больше, чем 80% времени. Сравнение трекинга по сценариям тестирования с ожиданиями разработчика дает также ценную обратную связь и самому разработчику.

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

ALM увеличивает ценность тестирования

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

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

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

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

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

Оригинал: http://www.agileconnection.com/sites/def[...]es/magazine/file/2015/Adopting%20ALM.pdf

Перевод: Александра Родсет

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• SDLC - жизненный цикл разработки системы
• Как именно Agile ALM может помочь?
• Инструментарий Agile ALM
• Внедрение Agile ALM
• Эволюция разработки - на пути к Agile ALM