Есть ли необходимость изменить традиционные подходы к тестированию? Что такое DevOps? Кто использует эту методологию? Наши специалисты сегодня ответят на эти вопросы, а также дадут советы по решению проблем с помощью интеграционного тестирования.

Как непрерывная разработка может снизить издержки в ALM

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

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

Непрерывная разработка снижает издержки ALM по ряду направлений, включая издержки, возникающие а случае задержек разработки и развертывания. Мы перечислим некоторые из них:

• Издержки на утверждение требований: Сбор требований и их утверждение – одна из самых страшных издержек в ALM. Ведь если требования не были собраны и утверждены должным образом, будет потрачено время на проектирование и разработку ненужного решения, которое не соответствует фактическим потребностям. Недопонимание приводит к затратам на доработку требований. Непрерывная разработка предполагает раннее и быстрое создание работающего кода, и требования могут быть утверждены уже на раннем этапе ALM цикла. Во многих проектах для утверждения собранных требований хватает даже разработанного на ранней стадии прототипа UI. При внесении поправок как можно раньше, можно избежать расходов на переработку более дорогого, уже готового ПО.
• Издержки на утверждение дизайна: Непрерывная разработка, со своими ранними и быстрыми сборками, помогает командам разработчиков приоритезировать важные и открытые вопросы дизайна, позволяя создавать различные прототипы и протестировать их на ранней стадии. Не озвученные вовремя вопросы о сложной архитектуре ПО являются одной из основных проблем дизайна. Непрерывная разработка позволяет получить ответы на эти вопросы раньше и быстрее, убрать их с пути и избежать дорогостоящей переработки уже готового ПО.
• Издержки на тестирование: В традиционных циклах ALM тестировщики и специалисты по контролю качества для проведения тестирования ждут сборку. Потом команда разработчиков ожидает, пока группа тестировщиков закончит тестирование и сообщит о дефектах и проблемах. Слишком много ожидания, которое приводит к пустой трате времени и человеческих ресурсов. В непрерывной разработке тесты автоматизированы и встроены в саму сборку. Тестировщики проектируют автоматизированные тесты и встраивают их в процесс сборки. Для этого им не нужно ждать, пока их коллеги завершат свою работу. Разработчики же сразу получают информацию о проблемах, которые выявляет автоматизированное тестирование, и устраняют их перед следующей сборкой. Издержки тестирования существенно сокращаются просто за счет использования автоматизированных средств и инструментов, и исключения ожидания в цикле ALM.
• Издержки из-за регрессионных ошибок и переделывания кода: Регрессионные ошибки проникают в сборки, если разработчики не дисциплинированы или не следуют установленному процессу регистрации последних изменений кода. Если по ошибке, вместо последней версии, внесена предыдущая, уже устраненные баги могут попасть обратно в сборку. И ошибки снова придется искать с помощью тестирования. Такой ситуации можно избежать при помощи автоматизированных процессов регистрации изменений, разработки и тестирования, чего, собственно, и требует непрерывная разработка. Сборки не могут считаться завершенными, пока не пройдут все автоматизированные тесты. Исправления кода из-за регрессионных ошибок полностью исключены.
• Издержки интеграции: При обычном подходе к ALM интеграционное тестирование производится как отдельный этап. Непрерывная разработка требует интеграции всех модулей при каждой сборке. Интеграционные тесты также образуют часть автоматизированных тестов. Это означает, что сборка не считается готовой, пока не пройдет полное интеграционное тестирование при каждом проходе. То есть нет дополнительных издержек, и при этом улучшается качество кода.
• Издержки внедрения: В ALM обычно есть отдельный процесс переноса сборок в продуктив. Это приводит к непредвиденным расходам при возможных задержках, а также различным издержкам, связанным с необходимостью останавливать продуктивную среду для техобслуживания и обновления. В случае же непрерывной разработки нет необходимости в отдельном цикле внедрения. Когда ежедневные или ежечасные сборки проходят все автоматизированные тесты на копии данных из продуктивной среды, новая сборка может быть перенесена в продуктив без каких-либо отсрочек.

Вывод

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

Переход к DevOps ускоряет развертывание и повышает ROI

Есть ли необходимость изменить традиционные подходы к тестированию? Что такое DevOps? Кто его использует? Эти и другие вопросы Маной Нарайанан, из корпорации Cognizant Technology Solutions, затронул на конференции STAREAST 2012 в сессии под названием «Тестирование в DevOps мире непрерывной поставке ПО». В ней он наглядно объяснил преимущества DevOps и его влияние на организацию.

Традиционные подходы к тестированию направлены на непрерывную поставку, что приводит к развитию узких навыков и сводит к минимуму развитие в других направлениях. Обмен идеями и взаимовыгодное сотрудничество ограничено, так как существуют барьеры между командами разработки, тестирования и развертывания. Нарайанан определил недостатки такого подхода как более длительное время ожидания и более высокий риск; по сути, разработчик может сказать: «Я не знаю, то ли я разрабатываю, чего хочет конечный пользователь».

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

Гибкая методология разработки и DevOps

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

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

«Этот подход, как и Agile, нацелен на то, чтобы развертывание нового функционала происходило как можно чаще. Но, в то время как Agile в основном фокусируется на функциональной и нефункциональной готовности приложений, DevOps делает шаг вперед и обеспечивает Операционную и Бизнес готовность», утверждает Нарайнан. Он отметил несколько сайтов, которые на сегодняшний день применяют модель DevOps, таких как Facebook, Etsy, Orbitz, Groupon и Flickr. В лидеры выбиваются компании с Web 2.0, полагающиеся на электронную коммерцию, где быстрые изменения и улучшенное время отклика являются первостепенными. В принципе, к ним же относится и Netflix, применяя NoOps подход.

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

Переход к DevOps

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

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

Управление, технология и одобрение стейкхолдеров

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

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

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