20/12/2021

Снизить количество ошибок в 2 раза: как релизная политика наладила тестирование

В 2020 году в банке появилось Управление релизами, которое внедрило релизную политику. Благодаря ему все обновления выходят вовремя, а автоматизированные системы банка работают стабильно и могут выдержать очень высокую нагрузку. Но так было не всегда. Рассказываем, как удалось наладить тестирование самых важных банковских систем. Делаем это вместе с Оксаной Моисеевой, руководителем Управления релизами, Кириллом Борисовым и Алексеем Бычковым, руководителями по нагрузочному тестированию.

Почему без релизной политики тестировать и выпускать релизы было сложнее

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

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

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

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

Что такое релизная политика и какие результаты дало ее внедрение

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

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

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

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

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

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

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

Оксана Моисеева

Руководитель релизного направления.

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

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

  • заранее выявлять ошибки совместимости;
  • тратить меньше времени на доработку и отладку системы;
  • улучшить качество тестирования;
  • повысить качество внедрения и сократить количество ошибок на проде.

До внедрения релизной политики, в начале 2020 года, на продуктиве было 114 ошибок. По плану их число должно было уменьшиться на 10%. Этот план удалось перевыполнить: за 10 месяцев работы количество ошибок сократилось до 52, то есть больше чем в два раза

Новая задача команды по релизной политике — сократить Time to Market релизов с трех недель до двух. Более частые релизы позволят уменьшить время от постановки задачи до выхода функции в прод. Для этого сейчас разворачиваются новые тестовые среды для релизов, которые требуют нагрузочного тестирования.

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

Как релизная политика изменила нагрузочное тестирование

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

Релизная политика сделала нагрузочное тестирование эффективнее — заранее известно, какие системы и функции будут в скоупе. Для каждого релиза тестировщики пишут подходящие скрипты, чтобы автоматизированные тесты охватили все изменения.

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

До запуска тестов нужно настроить профиль нагрузки: указать, например, что за час в системе выполняют условные 1 000 операций выдачи кредитных карт, выдают 5 000 потребительских кредитов или совершают 15 000 переводов по номеру телефона.

Кирилл Борисов

Руководитель нагрузочного тестирования.

В ходе нагрузочного тестирования выявляются разные дефекты. Многие связаны не с кодом, а с настройками тестовой среды: они не всегда совпадают с продакшеном.

После старта тестирования система автоматически рассчитывает количество виртуальных пользователей, а в дашборде отображается время обработки заявок, количество и характеристики ошибок. Тестировщик может отследить любую виртуальную заявку: какие этапы она проходила, сколько времени была в разных статусах.

Другие статьи по теме
0%

Банк ГПБ (АО) использует файлы cookie. Подробная информация –
в правилах по обработке персональных данных. Вы можете запретить сохранение cookie в настройках своего браузера.