Luxoft Training предлагает познакомиться с переводом статьи Пола Джеррарда «What Does DevOps Mean for Testers?».
Пол Джеррард – технический директор компании TestOpera Limited и руководитель UK Test Management Forum, обладатель премий EuroSTAR European Testing Excellence и European Software Testing Awards (TESTA).
Перевод и публикация выполнены с разрешения автора
История вопроса
В этой статье я хочу обсудить внедрение методологии DevOps с точки зрения тестирования и тестировщика. «Движение DevOps» (лучшего названия пока нет) развивается стремительно. Скорость внедрения новшеств в этой методологии, как и многие другие перемены, которые происходят в этой отрасли, очень высокая. При этом до сих пор нет четко сформулированного названия самого движения.
В зависимости от структуры вашей команды, от того, с кем вы разговариваете, методология DevOps может представлять собой как решение проблемы, так и самостоятельную цель. На некоторых предприятиях цель заключается в переходе к цифровым технологиям, и методология DevOps является частью общего подхода к обеспечению регулярного и высококачественного развертывания. Именно в этом смысле я рассматриваю DevOps в данной статье. Однако при реализации маркетинга технологий и услуг, связанных с методологией DevOps, эта цель может быть не совсем понятной. Проблема изменения культуры (или изменения поведения), требуемого для достижения успеха, зачастую недооценивается. Другое предположение, от которого я отталкиваюсь, заключается в том, что для тестировщиков, работающих в рамках методологии DevOps и находящихся под ее влиянием, эта методология является новинкой.
Я построил эту статью как введение в методологию DevOps для таких тестировщиков, а также как обсуждение ее влияния на методы тестирования. Если Вы являетесь опытным специалистом-практиком, использующим методологию DevOps, эта статья вам также может быть полезна. Если же Вы не являетесь тестировщиком, вы, по крайней мере, взглянете на вопрос с точки зрения тестировщика.
Для непосвященного читателя: что такое методология DevOps?
Простыми словами: DevOps — это понятие, обозначающее группу разработки и группу эксплуатации систем, которые более тесно сотрудничают между собой. В так называемом конвейере развертывания (от исходного программного кода до эксплуатации в производственной среде) разработчики автоматизируют какие-либо действия группы эксплуатации. Группа эксплуатации имеет возможность отслеживать действия разработчиков и оказывать на них некоторое влияние. При этом цель заключается в ускорении развертывания и внедрения программного обеспечения. Объединение группы эксплуатации (Ops) и разработчиков (Dev) (фактически в виде команды, использующей методы Agile) позволяет реализовать подход, который можно назвать «эксплуатация, основанная на методах Agile» (Agile Operations).
Очевидный результат успешного внедрения методологии DevOps заключается в сокращении количества времени, которое необходимо на то, чтобы изменение программного обеспечения прошло все стадии от идеи до эксплуатации в производственной среде. Когда разработчик говорит, что изменение программного обеспечения «сделано», переход к использованию этого изменения в производственной среде выполняется с помощью всеобъемлющей автоматизации. Автоматизированные средства и процессы используются при конфигурировании системы, в процессе сборки, при тестировании, развертывании в тестовой, промежуточной и производственной среде, при проведении мониторинга после завершения развертывания, при оценке и эксплуатации.
Итак, DevOps — это просто инструменты?
С одной стороны, цель методологии DevOps заключается в ликвидации узких мест в конвейере развертывания за счет использования автоматизации. Но автоматизацией многостадийных процессов все равно необходимо управлять. Многие автоматизированные процессы на самом деле не являются автономными — они не могут выполняться без вмешательства человека (для выполнения технического обслуживания и обработки нестандартных ситуаций). Полностью автоматизированный процесс DevOps не имеет смысла без учета влияния человеческого фактора. Несмотря на то что средства автоматизации выполняют много черновой работы, именно люди, управляющие процессом, обеспечивают его успешное (или неуспешное) выполнение.
Итак, DevOps — это просто разработчики (Dev) и группа эксплуатации (Ops), тесно сотрудничающие с использованием средств автоматизации?
Нет, опять неверно. Передача управления между автоматизированными процессами часто включает в себя другие процессы — обычно тестирование того или иного рода. Автоматизированные тесты создаются разработчиками и тестировщиками. Результаты этих тестов нацелены на предоставление достаточной информации, необходимой для выполнения других процессов или, что бывает чаще, необходимой людям, которые выполняют переход от одной стадии конвейера к другой. Тестировщики и разработчики, которые осуществляют тестирование, обеспечивают успешное и надежное выполнение процесса DevOps.
Голова кругом! И что же все-таки означает DevOps? Это прогрессирующая новейшая дисциплина. Данный вопрос детально рассмотрен в статье «What Is DevOps?», которая появилась за несколько недель до написания данной статьи. Как вы уже поняли, определение понятия DevOps еще не сформулировано окончательно. Возможно, никогда и не будет.
Что это значит для тестировщиков? Это значит, что до сих пор не существует «единственно верного пути» и что ваша роль в режиме DevOps, который постоянно развивается (а каждый режим постоянно развивается), еще окончательно не установлена. Существуют два момента, которые вы можете реализовывать:
1) обращать внимание на болевые точки и прилагать усилия к тому, чтобы уменьшить степень их негативного влияния;
2) выявлять возможности, которые позволяют оптимизировать процесс DevOps.
Если и существует единственная мантра, которая наилучшим образом описывает движение к методологии DevOps, то она звучит так: «Если это неприятно, делайте это чаще». Это может показаться похожим на клише, однако я буду пользоваться этим выражением в качестве контекста для внедрения и совершенствования практических навыков по тестированию с использованием методологии DevOps.
Если это неприятно, делайте это чаще
Трудности или неприятные ощущения, которые мы испытываем при выполнении определенной работы, влияют на нас отрицательно. Если нам не нравится какое-либо задание, то мы стремимся отложить его. Когда же мы, наконец, принимаемся за это неприятное дело — становится еще невыносимее. Визит к стоматологу, уборка в гараже, интеграция программного обеспечения, тестирование и т. д. Опыт говорит о том, что чем реже мы выполняем такие задания, тем неприятнее их выполнение. Мартин Фаулер (Martin Fowler) предложил три причины того, почему частое (или даже непрерывное) выполнение определенных заданий уменьшает неприятные ощущения.
Первая причина заключается в том, что большие и сложные задания трудно планировать, ими трудно управлять и их трудно контролировать. Разбиение больших заданий на несколько маленьких позволяет облегчить их выполнение и снизить степень риска, а если что-то пойдет не так, будет проще все вернуть в прежнее состояние. Вторая причина – многие задания (и тестирование в этом плане представляет собой наилучший пример) обеспечивают возможность обратной связи. Эта обратная связь, если она поступает на ранней стадии и достаточно часто, позволяет быстро реагировать на возникающие проблемы, прежде чем будет впустую потрачено время. И третья причина: если мы осуществляем какую-либо деятельность чаще, мы лучше справляемся с ней. Мы учимся делать эту работу эффективно. Кроме того, мы находим возможности автоматизировать ее тем или иным способом.
С точки зрения тестировщика эта мантра вынуждает более серьезно подходить к понятию автоматизации при осуществлении процесса тестирования. Если производится ручное вмешательство (обычно между автоматизированными стадиями в процессе DevOps), то оно должно рассматриваться как болевая точка: узкие места, причины задержек и потенциально ненадежные и склонные к появлению ошибок аспекты процесса.
Ручное тестирование неприятно. Да, вам может доставлять удовольствие проводить исследовательское тестирование, вы можете считать, что только вы как человек сможете обнаружить те заковыристые ошибки, которые автоматика никогда не найдет, что только вам как тестировщику можно доверять, чтобы не допустить катастрофу.
Вас как тестировщика может беспокоить, будет ли работа по тестированию выполнена надлежащим образом, если она поручается разработчикам или автоматизированным средствам. Если это для вас неприятно, делайте это чаще.
Тесты, автоматизация и доверие
Ведется много споров вокруг значения, например, проверок и тестирования, и вокруг того, насколько мы можем полагаться на тестировщиков, на проверки и на автоматизированные средства (The New Model and Testing v Checking).
Я не говорю, что мы должны полностью полагаться на автоматизированные проверки. Нам понадобится применить более сложный подход. Однако мы можем для целей этой статьи, по крайней мере, разделить тесты и деятельность по осуществлению тестирования на четыре компонента:
1) проверки, которые могут быть автоматизированы разработчиками в составе покомпонентных проверок и процессов непрерывной интеграции;
2) проверки, которые можно автоматизировать (обычно силами системных тестировщиков) для выполнения транзакций на уровне API, линий связи или всей системы;
3) тесты, включающие проверки совместимости и позволяющие продемонстрировать совместимость с браузерами, операционными системами и платформами;
4) тесты, которые может выполнить только человек.
В данной статье могу лишь сделать предположение, как осуществить такое разделение — каждая среда имеет свои особенности. Наиболее подходящий вопрос для данной статьи – как тестировщику «освободить себя» от поздних ручных проверок? Ранее я писал об исключении поздних ручных проверок. Это требует предусмотрительности и доверия.
Необходимо сконцентрировать внимание на следующих моментах:
1. Если это возможно, ручные проверки, которые могут быть выполнены на уровне компонентов, должны быть возложены на разработчиков. Как тестировщик, вы можете предложить выполнить эти тесты во время сеансов парной или коллективной работы. Вы можете написать их сами и включить их в режим непрерывной интеграции.
2. Для тестирования пользовательского интерфейса и комплексного тестирования может потребоваться использование автоматизированных средств. Такое тестирование следует свести к минимуму, так как оно долго выполняется, является нестабильным и часто требует обслуживания. Подумайте о том, нужно ли его выполнять при каждой проверке программного кода или можно отложить для использования только на крупных, менее частых релизах.
3. Какие неавтоматизируемые тесты можно выполнять на компонентах, которые еще не интегрированы в предвыпускную версию? Можно ли выполнять ручное тестирование в сеансах парной работы с разработчиками? Существуют ли альтернативы такому тестированию? Может ли помочь работа с архивными документами, прототипирование с использованием подхода BDD? Можно ли выполнять проверки пользовательского интерфейса на макетах или каркасных конструкциях?
4. Какие проверки необходимо выполнять только вручную в отличие от проверок, которые требуется оставить для регрессионного тестирования (они являются кандидатами для автоматизированного тестирования)?
Выше я упомянул о доверии. Другой вопрос заключается в том, как надежно тестировать систему, если не будет позднего ручного тестирования. Представьте себе среду, в которой все тестирование осуществляется автоматизированными средствами. Поверите ли вы, что разработчики надлежащим образом выполнят тестирование? Смещение забот о тестировании влево должно развеять ваши сомнения. Если вы как тестировщик действуете, как следопыт: для того чтобы идентифицировать и оценить риски, выбрать тесты и обеспечить, чтобы они были встроены в процессы разработки и автоматизации, то ваши опасения могут быть сведены к минимуму.
Естественно, вы должны перестать считать себя охранником качества, последним рубежом обороны, единственным человеком, которому не все равно. Вам приходится больше думать, как провидец, определитель рисков, управляющий рисками, следопыт, координатор и инструктор или наставник.
Практика, мониторинг и совершенствование
При всем желании если перестать полагаться на поздние ручные проверки, ошибки все же могут быть. Когда программное обеспечение выпускается в производство, обнаруживаются проблемы. Одной из ключевых дисциплин методологии DevOps с точки зрения эксплуатации является более глубокий мониторинг.
Мониторинг на каждом уровне — от компонентов и простых транзакций в приложениях до интеграции и обмена сообщениями и, конечно, самой инфраструктуры. Одна из целей мониторинга заключается в том, чтобы формировать сообщения об отказах до того, как пользователи испытают на себе их последствия. Это довольно амбициозное утверждение, но оно определяет конечную цель.
Когда проблемы встречаются в производственной среде, то задача заключается в том, чтобы использовать аналитическую информацию, полученную при выполнении мониторинга для того, чтобы не только отследить причину и устранить ее, но и для уточнения процесса тестирования (автоматизированного или ручного) и снижения вероятности возникновения подобных проблем в будущем. Роль тестирования и аналитической информации в функционировании всего конвейера определяется и обсуждается в статье «Thinking Big: Introducing Test Analytics».
Можно назвать автоматизированное тестирование процесса DevOps мониторингом. Когда мониторинг объединен с производственной средой, можно сказать, что мониторинг на протяжении всего процесса DevOps с заходом в производство расширяет сферу применения тестирования. Таким образом, методология DevOps не уменьшает роль тестировщиков.
Заключение
Недавно меня спросили: «В каком случае не следует пытаться применять методологию DevOps в организации?». Это хороший вопрос. Думаю в его основе лежит опасение, должна ли методология DevOps стать нормой и должны ли тестировщики обратить на это внимание. Мой ответ прост.
Почему бы вам не сделать так, чтобы разработчики и специалисты по эксплуатации разговаривали друг с другом? Почему бы вам не начать получать более надежные сборки и развертывания в тестовой и производственной среде? Почему бы вам не использовать лучшие технологии для более точного, эффективного и информативного конвейера? Методология DevOps является хорошим делом, однако не всегда легко достичь требуемого уровня ее использования. Не говоря уже о том, что она требует изменения культуры, а это не так просто.
С точки зрения тестировщика, методология DevOps оказывает влияние в большей степени на ранних стадиях проектов, вынуждает более серьезно задумываться об автоматизации тестирования, предоставления информации и принятия решений. Тестировщикам следует стремиться к использованию методологии DevOps, так как она дает возможности для выполнения действий в упреждающем режиме, получения более широких полномочий и уважения в проектной команде.
11 ноября Пол Джеррард даст мастер-класс в Москве на тему «Тестирование в эпоху цифровых технологий: DevOps, ChatOps и автоматизация для поддержки тестирования».
Автор: Luxoft
