CNews: «Без TestOps сегодня невозможен полноценный DevOps» – согласны ли вы с этим утверждением?
Евгений Сабиров: Да, все обстоит именно так. Дело тут не столько в идеологии, сколько в особенностях современных требований к программным продуктам. Продукты должны развиваться в соответствии со стремительно меняющимися требованиями рынка, а для этого разработчики должны наладить практически непрерывную поставку «на прод» разнообразных фишек, обеспечивающих ценности для клиента. Чем меньше пауз будет в этом процессе – тем лучше и успешней будут компании, для которых трудятся разработчики.
Если говорить о тестировании, то надо понимать, что это этап, который не добавляет в продукт никакой ценности, но стоит денег и времени. Конечно, важность тестирования никто не оспаривает: если релиз, содержащий ошибки, уйдет в «в продакшн», то проблемы будут огромными: прямые убытки, потери клиентов и т.д., но трата ресурсов на процесс тестирования — выбор меньшего из зол. Поэтому стоимость этапа тестирования нужно максимально сокращать, это же касается и его продолжительности. Несомненно, TestOps – шаг именно в эту сторону.
Организация процессов TestOps в деталях зависит от особенностей создаваемых приложений, структур команд разработки и ряда других факторов.
CNews: А технологические и архитектурные особенности создаваемых решений влияют на организацию тестирования?
Евгений Сабиров: Теоретически тестирование не должно зависеть от инструмента разработки. Но практически архитектура все же оказывает определенное влияние на все DevOps, но на TestOps, скорее, в плане менеджмента процессов.
Например, мы преимущественно используем микросервисную архитектуру, поэтому у нас нет единой группы тестирования, которую возглавлял бы выделенный менеджер, распределяющий задачи, следящий за отчетами и т.д. В каждой команде, ответственной за продукт или его отдельную часть, есть собственные тестировщики.
Мультиплатформенность также усложняет процессы тестирования – решения для каждой платформы нужно тестировать отдельно. Принцип остается тем же, но необходимость параллельных процессов – на каждую платформу свой – увеличивает нагрузку на тестировщиков, а также требует дополнительных инструментов.
Про облака ничего сказать не могу – в банковской практике эти технологии по понятным причинам не жалуют. Конечно, в нашей внутренней инфраструктуре присутствуют элементы, построенные по облачным технологиям, но это не облака в традиционном смысле.
CNews: Почему ваш банк решил самостоятельно разрабатывать софт, а не брать готовое решение и настраивать его под свои нужны?
Евгений Сабиров: Опять же – это требование рынка, который требует быстрых реакций на происходящие изменения. Использование готовых решений снижает динамику, как и привлечение внешних подрядчиков. В финансовом бизнесе разработчики должны быть внутри банка, коммуникации с ними должны происходить очень быстро, гораздо быстрее, чем это возможно с внешней компанией, при взаимодействии с которой коммуникационные издержки неизбежны. Такая ситуация существует давно, причём не только в банковской сфере.
CNews: Каковы дополнительные выигрыши от in-house разработки в данном случае? Дополнительная гибкость, соответствие требованиям российских регуляторов, меньше стоимость «на круг» или что то иное?
Евгений Сабиров: Как правило, внутренняя разработка обходится дешевле для банков. Кроме того, на практике оказывается, что созданное силами своих программистов решение оказывается более гибким. В него не только проще добавлять новые функции, но и его проще масштабировать.
CNews: Сколько по времени заняла разработка? Сколько людей задействовано в развитии созданного?
Евгений Сабиров: Система работает давно, ее создали еще в те времена, когда существовал наш предшественник – «Банк 24», а уже шесть лет, как мы являемся банком «Точка». Сколько людей разрабатывали ту систему «с нуля» сейчас сказать не могу, но сейчас из более чем двух тысяч сотрудников нашего банка порядка шестисот заняты в ИТ и значительная часть из них – в разработке, тестировании и сопровождении системы.
CNews: Как проводили тестирование? Сколько людей участвует в тестировании?
Евгений Сабиров: В каждой кросс-функциональной команде, как правило, от одного до трёх тестировщиков, а общее их количество – около 50.
CNews: Сколько тестов, в среднем, выполняют перед выпуском релиза?
Евгений Сабиров: Количество исполняемых тестов разное и от команды к команде, и от релиза к релизу – его подбирают индивидуально, в зависимости от особенностей задачи и руководствуясь принципом разумной достаточности. Общее количество написанных тест-кейсов мы точно не подсчитывали, хотя с внедрением Test Management System сможем ответить и на этот вопрос.
CNews: Какие инструменты вы используете для TestOps?
Евгений Сабиров: В наших текущих реалиях неизбежно сочетание ручных и автоматических тестов. Автотесты у нас различные, часть созданы в инструментах тестирования, часть – написаны кодом. Для кросс-платформенного тестирования мы используем Selenoid. Активно используем Jmeter, причем как для нагрузочного тестирования, так и для ряда других задач, например, для тестирования API. Для организации и поддержки TestOps с некоторого времени важное место занимает Allure TestOps.
CNews: Для каких задач управленческого характера используете Allure TestOps?
Евгений Сабиров: Allure – наша Test Management System, которая существенно упрощает как организацию работы, так и повседневные задачи тестировщиков. Это становится заметно, когда мы спускаемся в поля тестирования. Фиксация отчетов по тест-кейсам существенно упрощает работу в ряде ситуаций, кроме очевидных – организации регрессионного тестирования и т.д. – она бывает крайне полезной при передаче задач от тестировщика к тестировщику. А такая необходимость возникает часто, причин может быть много: отпуск, больничный, увольнение.
Управление процессами тестирования в Allure происходит из «единого окна». Поэтому каждый управляющий тестированием – а у нас, напомню, тестирование выполняют внутри каждой кросс-функциональной команды разработчиков – может быть уверенным, что заданный «тест-ран» отработан, что проведены все тесты, как ручные, так и автоматические.
Allure полезен как для управления, так и для ряда практических задач тестировщиков. Например, при создании сценария автоматического тестирования, расширяющего возможности ранее применявшихся ручных, специалист может обратиться к отчетам о ранее проведенных тестах для получения детальной картины. Заметим, что верно и обратное: при разработке ручных кейсов, которые должны продолжить ветку автоматических, также можно смотреть данные ранее запускаемых тест-кейсов, историю ошибок и т.д.
CNews: Чем обусловлен выбор именно этого программного обеспечения: ценой, импортозамещением, доступностью русскоязычной поддержки?
Евгений Сабиров: Выбор новой системы для TestOps – процесс непростой. Мы выполняли переход на решение Qameta с аналогичной системы другого производителя. Система была тоже российского производства, поэтому поддержка, нам доступная, и раньше была русскоязычной. Замечу, что продукт Qameta Software оказался user-friendly, как по организации, так и по интерфейсу, что ускорило процесс перехода на новую систему и существенно упрощает повседневную работу с Allure.
В решении о переходе оказалась важна общность взглядов – наших и разработчика – важно понимание TestOps сегодня и его перспектив, которое у нас с основателями Qameta/создателями Allure действительно очень похоже. Перед выбором системы мы активно общались с представителями разработчика и даже созванивались с представителями руководства Qameta. Общность в понимании перспектив важна в практическом плане: функции, нужные нам в будущем, с высокой вероятностью своевременно будут появляться в продукте.