Контакты

Нить Ариадны: тестирование как способ улучшить процесс разработки ПО в банках

Портал Интеллектуальный банк - 14 августа 2013 - Ирина Рапинчук, Павел Северин, Елена Ермохина, EPAM

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

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

Практический аудит

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

Скажем, применительно к тем же тест-кейсам он позволит: 

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

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

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

Прозрачность каждой операции

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

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

Об этом свидетельствует, в том числе, статистика ее использования среди заказчиков EPAM Systems. Так, на базе JIRA для одного из крупнейших инвестиционных банков команда EPAM внедрила более 150 специализированных элементов управления задачами. Они были разработаны с учетом потребностей заказчика и покрывали широкий спектр операции - от формализации процесса уточнения требований до учета издержек и сбора метрик. Это позволило банку выявить и исправить наиболее проблемные участки в разработке и тестировании. Дополнительно появилась возможность в режиме реального времени контролировать процессы и отслеживать риски и отклонения от планов. 

К слову, сейчас JIRA используется для управления проектами и внутри самой EPAM Systems. 

Виртуализация, автоматизация и CI для тестовых сред 

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

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

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

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

О преимуществах Continuous Integration стоит сказать подробнее. Этот подход позволяет полностью автоматизировать процесс от внесения изменений в программный код до получения результатов автоматизированных тестов. В автоматическом режиме проверяется целостность кода, запускаются unit-тесты и проводится сбор результатов, создаются и устанавливаются в тестовые среды сборки кода, запускаются автоматизированные функциональные и регрессионные тесты. 

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

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

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

Не менее важными параметрами следует считать набор стандартных функций решения и подключаемых библиотек, степень гибкости структуры CI-проекта, возможность получать результаты и отчетность в нужном виде, наличие поддержки со стороны производителя решения. Примером использования средств виртуализации, автоматизации и CI может служить проект, который был реализован EPAM Systems для инвестиционного банка. 

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

Удалось реализовать параллельное выполнение регрессионного тестирования с использованием фреймворка TAF (разработка EPAM для автоматизации тестирования) на пяти виртуальных машинах под управлением CI-инструмента. В итоге стало возможно получать результаты полностью выполненных регрессионных тестов каждое утро.

Рис.1 Организация параллельного выполнения автоматизированных тестов с использованием средств CI, виртуализации и фреймворка TAF. 

Интеграционное тестирование

Еще одна нередкая проблема, которая выявляется в ходе аудита и влияет на качество ПО, - это отсутствие или слабая организация интеграционного тестирования. Интеграционное тестирование всегда необходимо в ситуациях, где тот или иной банковский процесс подразумевает взаимодействие разных систем. К примеру, выдача кредита клиенту начинается с фронт-офисных решений, проходит через мидл-офис и заканчивается генерацией отчетности в бэк-офисе. Покрыть такие процессы end-to-end тестированием и провести его в разумные сроки не всегда возможно. В этом случае хорошим выходом может стать автоматизация тестирования на уровне интерфейсов взаимодействия систем и с использованием возможностей интеграционных шин (Enterprise Application Integration, EAI), если они используются не только в качестве транспорта, но и оказывают влияние на бизнес-процесс.

Рис.2. Для end-to-end-тестирования сложная система оказывается черным ящиком. Интеграционное тестирование за счет появляющейся прозрачности помогает найти больше ошибок и локализовать их. 

В числе проблем, которые осложняют тестирование банковских систем с EAI, можно выделить недостаточный контроль за изменениями интерфейсов, необходимость выполнения большого количества тестов и генерации большого объема тестовых данных в различных форматах. Кроме того, участие в одном бизнес-процессе часто принимают десятки программных компонентов с разными режимами интеграции (синхронный или асинхронный). При этом некоторые из таких компонентов могут оказаться недоступными для тестирования. Свою ложку дегтя способна добавить и исторически сложившаяся неоптимальная интеграционная архитектура. 

Как избавиться от этих трудностей и качественно провести интеграционное тестирование?

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

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

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

Лабиринт становится проще

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

Оригинал публикации