TestOps:

Будущее тестирования

Все статьи

От DevOps к TestOps: как ускорить процессы тестирования новых приложений и ПО

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

 

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

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

Как развивалась культуры разработки

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

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

Однако, следует отметить, что в разработке программных продуктов задействованы специалисты, объединенные в три крупных функциональных блока: разработка, тестирование и внедрение/эксплуатация. Каждое направление требует специалистов с профильными квалификациями, специфического менеджмента и, по сути, специализированной версии DevOps. Порядка трех лет назад стали говорить о TestOps, как о специфическом наборе инструментов и техник, позволяющем навести порядок уже в процессах тестирования. В силу ряда исторических причин тестирование отставало от разработки по степени осмысления, происходящих внутри специфических процессов, по уровню проработанности подходов, наличию широко известных «best practices» и по наличию развитых специализированных инструментов. Но ситуация изменилась.

От DevOps к TestOps

Прежде всего, динамика внедрения новых процессов в компаниях, которая требует быстрого развития имеющихся программных продуктов — запуска новых сервисов и функций, оперативный выпуск «заплаток» и т.д. — а также жесткие требования к «time to market» для новых разработок. Если раньше обновления могли появляться раз-другой в год, то теперь для большинства решений частота сократилась до трех-четырех недель. Критичные обновления надо вносить еще быстрее: «Hotfix должны занимать не более пары дней, — уверен Дмитрий Демин. — Большее промедление может сильно навредить как клиентам, так и дальнейшему бизнесу компании-разработчика». Это и потребовало от разработчика внедрения TestOps как отдельного направления. «Как мы теперь понимаем, компания Qameta Software стояла у истоков этого направления, создавая систему Allure для отделов тестирования», — добавляет Дмитрий Демин.

depositphotos137026300xl2015600.png

Почему TestOps нужен разным компаниям

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

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

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

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

Сегодня программой Allure пользуются команды разработчиков по всему миру. Интересно, что эти команды далеко не всегда создают коммерческие программные продукты. Мощные отделы по созданию программного обеспечения трудятся внутри компаний разной специализации: банков, строительных структур, телеком-операторов и т.д. Стоящие перед ними задачи тоже усложняются, как и требования к скорости разработки, поэтому этим командам тоже нужен DevOps. Со временем все они сталкиваются с необходимостью интегрировать тестирование в новые бизнес-процессы, и тогда приходят к идеологии и подходам TestOps. Провести жесткую границу, в каких ситуациях командам уже необходимы DevOps/TestOps, а когда еще можно обойтись ручным управлением, довольно сложно — все зависит от ряда факторов, которые имеют отношение как к самой команде, так и к масштабам стоящих перед ней задач разработки. Однако, количество компаний, для которых TestOps становится «must have», становится все больше.

Какое будущее ждет разработчиков

Появление новых технологий, архитектур, фреймворков и платформ, теоретически, не должно влиять на процессы тестирования, которые в идеале должны быть независимы от инструментов. Однако, на практике это не так: новые решения требуют повышенного внимания и, как следствие — более тщательного тестирования. С усложнением продукта и его окружения появляется больше вариантов поведения у всего решения, ответом на такую ситуацию выступает увеличение количества тестов и их усложнение. В итоге опять приходим к необходимости TestOps и к актуальности Allure. «Без наличия TestOps сегодня идеальный DevOps уже невозможен», — уверен Дмитрий Демин.

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

Новости