Банковское обозрение

Финансовая сфера

  • Как технологии тестирования сокращают time to market банковских продуктов
24.06.2019 Best-practice
Как технологии тестирования сокращают time to market банковских продуктов

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



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

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

Именно поэтому ускорение time to market как комплекс инициатив по внедрению методологий, процессов и инструментов автоматизации тестирования (QA), непрерывного развертывания и интеграции (CI/CD), DevOps — ключевой ориентир для компаний, находящихся хоть и в разных весовых категориях, но в одном конкурентом поле с молодыми финтех-стартапами, умеющими действовать стремительно.

Почему автоматизация так важна и чем грозит ее отсутствие

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

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

К сожалению, даже если IT-отдел понимает важность изменений, многие «традиционные» компании не принимают доказательства этого, не осознавая скорость возврата инвестиций от автоматизации.

Мы попробовали разобраться в трех ключевых проблемах» бизнеса в отношении разработки продуктов и дать несколько советов по их решению.

Долго

Рутина, повторяющиеся операции и отсутствие четко регулируемых процессов — первопричины срыва сроков. Смоделируем ситуацию с небольшим упрощением:

Разработчик: код готов, можно разворачивать и тестировать.

Инженер: ночью я не работаю, завтра разверну.

Тестировщик: в планы поставлю, сегодня уже все занято.

Прошли тесты, нашли три minor issues.

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

Инженер: опять то же самое разворачивать…

Тестировщик: это я уже тестировал, проверю только баги.

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

Простая автоматизация сборки и регрессионного тестирования может уменьшить ФОТ проекта до 10%, а автоматизация подготовки тестовых данных до — 12%.

Как бороться с описанной выше проблемой? Одно из решений — выявить наиболее затратные по времени задачи, чтобы сравнить трудозатраты на ручной и автоматизированный процессы. К примеру, простая автоматизация сборки и регрессионного тестирования может уменьшить ФОТ (фонд оплаты труда) проекта до 10%, а автоматизация подготовки тестовых данных до — 12%.

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

Дорого

Чем позже обнаруживается баг, тем дороже его исправление. Объясним на примерах:

Вариант 1. Разработчик написал код, в котором выявили критическую ошибку только через одну-две недели (см. диалог выше). Разработчик уже работает над другой задачей, но в попытке понять, что он делал со старой задачей и почему реализовал код именно так, он потратит какое-то время. Уже проведенное тестирование придется повторить после исправления ошибки.

Вариант 2. Разработчик к вечеру написал код, который нажатием нескольких кнопок был отправлен на автоматически развернувшееся виртуальное тестирование. По коду ночью «прошлись» автотесты, а уже утром команда получила полный отчет по всем багам. Работает принцип «сломал — тут же почини».

Почему подобная простейшая оптимизация даст значительный эффект? Причин несколько:

• разработчик все еще работает над той же частью программного кода, он еще не забыл, что делал месяц назад, ему не нужно переключаться между контекстами, соответственно корректировки он вносит буквально «на лету»;

• ветки кода не успели размножиться на последующие релизы, поэтому не придется исправлять один и тот же баг сразу в нескольких местах;

• другие разработчики не вносят изменения в этот содержащий ошибки программный код;

• тестировщик еще не успел потратить время на долгое регрессионное тестирование, которое придется повторять после исправления найденной ошибки.

Итог: экономия ФОТ за счет исключения ручного труда и соблюдения таймлайна проекта очевидна.

Неидеально

Приведем два простых примера из отраслей fintech и e-commerce, которые буквально начали срастаться в эпоху развития маркетплейсов и экосистем. В конце мая этого года в работе систем эквайринга и авторизации Райффайзенбанка возникли серьезные проблемы: платежи клиентов Банка по дебетовым картам не уходили конечному получателю, при этом средства клиентов оставались заблокированными, в результате чего проведение операций невозможно. А интернет-магазин «Связной» из-за сбоя в программном обеспечении в течение 15 минут продавал смартфоны по заниженным ценам — например, iPhone 8 с объемом памяти 64 Гб можно было заказать примерно за 6000 рублей.

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

Как бороться с этой проблемой? Через аудит и выстраивание процессов. Идти шаг за шагом от первого быстрого результата (например, внедрения автоматической сборки и развертывания приложений) к полной автоматизации процессов с систематическим внедрением вендорских инструментов, работой с автоматизацией и нагрузкой, средами, стендами, тестовыми данными и т.д.

Важно осознавать, что только наличие квалифицированных экспертов (как в штате, так и на подряде) станет гарантией результата. Опыт показывает, что при разработке ПО некачественный подбор персонала с невысокой оплатой «убивает» проект. Ни один чемпион-автоматизатор-DevOps-архитектор от подрядчика не разглядит все тонкости без грамотных разработчиков продукта, менеджеров проектов и тест-менеджеров со стороны заказчика.

Ускорение Time to Market на примере кредитного сервиса Банка СОЮЗ

Отлаженное тестирование напрямую влияет на основные бизнес-процессы. Прибыль же зависит от лояльности аудитории, которая напрямую связана с качеством конечного продукта и оперативностью запуска сервиса. Логика очевидна, верно? В случае с автоматизацией даже одной процедуры в Банке СОЮЗ компания получила на выходе многократное ускорение time to market по сравнению с ручными тестами.

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

Опыт показывает, что при разработке ПО некачественный подбор персонала с невысокой оплатой «убивает» проект

Наша команда сделала выбор в пользу подхода Continuous Integration (CI). Он сводился к автоматизации сборки, установки и тестирования функциональности интеграционной шины. Это было сделано для максимально быстрого выявления потенциальных недочетов и решения интеграционных проблем. Стоит учесть, что благодаря непрерывному формированию онлайн-копий банковских систем (интернет-банка, базы данных клиентов и системы обработки кредитных заявок) тестирование и доработка функциональности шины проводились независимо от работ в других частях конвейера.

Процесс создания и обработки кредитных онлайн-заявок состоит из многих этапов: формирования заявки, проверки паспорта и запроса данных о клиенте, построения графика платежей, подтверждения заявки… Запуск шины был призван реализовать по меньшей мере 400 таких сценариев. Ранее доработки любого из внешних приложений требовали большого количества ресурсов для корректировки работ внутренних систем и последующей перепроверки. Однако после внедрения интеграционной шины сервисы «разбились» на единые службы. Это значительно облегчило внедрение в конвейер изменений. Например, единую задачу обработки заявки на кредит стало возможным «расщеплять» на подзадачи, вроде «проверить данные, внесенные клиентом», «получить данные по истории выплат по кредитам», «рассчитать кредитный рейтинг», «отобразить баланс счета» и т.д. Таким образом, обновления стало легко вносить в отдельные части шины. Автоматически запускаемые проверки дали возможность отслеживать изменения во внешних приложениях и переносить их на шину, проверяя качество, скорость и безопасность функционала.

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

Исключение риска «человеческих» ошибок и другие выгоды

При создании продукта в условиях неоптимально выстроенных процессов высок риск релиза с серьезными недочетами и излишними временными тратами. В результате бизнес несет дополнительные расходы вследствие оплаты непродуктивного труда персонала (из-за срыва дедлайнов и «растягивания» процессов, из-за корректировки критических или блокирующих ошибок).

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

Кстати, некоторые виды работ едва ли осуществимы усилиями одной команды — иногда на задачу с горящими сроками требуется узкоспециализированный специалист (например, ModBus, Clojure или Erlang) на несколько дней. Именно поэтому все чаще мы наблюдаем ситуацию, как IT-подразделения крупных компаний переходят от работы с подрядчиками (у которых как раз есть такая экспертиза) к глубокому партнерству, интеграции команд с обменом опытом и смартсорсингу.

Если собрать все сказанное воедино, бизнесу и IT стоит опираться на следующие постулаты.

1. Чем меньше автоматизации и больше рутины, тем выше риск ошибок и сильнее растягивание сроков.

2. Чем позднее будет выявлен баг, тем дороже обойдется его исправление.

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

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

Советы экспертов «Инфосистемы Джет»

Для наиболее эффективного перехода на автоматизированное тестирование:

1) не стремитесь сразу «стать IT-компанией» и ускорять time to market на всех проектах. Начните с жизненно важного: исследуйте процессы, обозначьте ожидания и границы проекта, соберите команду экспертов и оцените план по срокам, рискам и стоимости;

2) используйте подрядчиков для автоматизации процессов — это «разгрузит» ваших специалистов. При этом не советуем экономить, отдавая одну систему в руки большого количества разных подрядчиков. Слабая интеграция команд способна нанести намного больший вред, чем высокая ставка за человеко-день;

3) помните об экономическом эффекте оптимизации: ручные, монотонные и часто повторяющиеся операции однозначно следует автоматизировать;

4) уходите от каскадных моделей и учитесь работать по Agile-спринтам, разделяя работу команд;

5) внедряйте метрики, позволяющие командами видеть свой прогресс;

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

7) внедряя методологии ускорения time to market (QA / CI / CD / DevOps), не забывайте материально мотивировать всех участников процесса;

8) анализируйте процессы, в которых имеются временные простои и проблемы с качеством. Внимательно отслеживайте статистику по ошибкам и причинам их возникновения, не допуская их повторения в будущем;

9) боритесь с «узкими» местами — к примеру, найдите решение распространенной проблемы объединения всех веток кода в релизную в последний день перед началом приемочного тестирования. Это даст значительный эффект, измеряемый в снижении количества ошибок и уменьшении трудозатрат.




Присоединяйся к нам в телеграмм
Сейчас на главной