Происходящая в крупнейших банках трансформация статуса ряда топ-менеджеров от IT-директора (CIO, «главного по IT») к Chief Digital Officer (CDO, «главного по данным») привела к радикальному изменению отношения к обеспечению качества и тестированию банковского ПО.
Когда стало понятно, что futurebanking — это симбиоз традиционного банкинга, в основе которого лежит умение управлять рисками, и IT, придающими помимо всего прочего гибкость кредитно-финансовым организациям, в лексикон банкиров прочно вошел модный в финтех-сообществе термин disruption. У этого короткого слова очень много смыслов, но чаще всего его используют для обозначения разрушения или коллапса как небольших стартапов, так и целых индустрий в экономике вследствие упущенных возможностей из-за негибкого управления (чаще всего — значительного времени вывода на рынок, time to market) или ошибок в программных продуктах, посредством которых осуществляется это управление.
Андриссен плохого не посоветует
Одним из значимых маркеров этого времени стала культовая статья Марка Андриссена (Marc Andreessen), члена совета директоров компании Hewlett-Packard, «Why Software is Eating the World» («Почему программное обеспечение съедает мир»), опубликованная в августе 2011 года в The Wall Street Journal. Необходимо отметить, что Андриссен до этого момента был более известен как весьма успешный и удачливый соучредитель одной из крупнейших в США венчурной инвестиционной компании Andreessen Horowitz.
Эта статья заслуживает прочтения всеми теми, кто хотел бы понять, почему выглядевшие ранее незыблемыми некоторые отрасли мировой экономики вдруг оказались разрушенными под напором информационных технологий, по выражению автора, софтом.
Они просто не смогли или не успели ничего противопоставить гибким и удушающим объятиям, например, социальных сетей по отношению к традиционным СМИ. Банкирам повезло несколько больше, у них была надежная опора в лице центральных банков. Поэтому у них было время понять, глядя на других, что надо меняться, становиться инновационными и гибкими, иначе disruption неизбежен
Но в первом абзаце этого анализа указано, что disruption наступает и по другим причинам, а именно из-за некачественного ПО. Можно внедрить «лучшие в своем сегменте» продукты и проиграть битву. Примеров тому не счесть. Главная причина — несоответствие архитектуры программных продуктов и софта тому, что от них ожидалось на этапе проектирования, написания и внедрения. Поэтому порой напичканные самыми современными IT банки не могут поспеть за рынком. Вся их энергия уходит на попытки управления «хаосом» и «зоопарками приложений», а также на латание дыр, оставшихся на радость хакерам от нерадивых программистов.
Именно эти причины заставили крупнейшие банки мира заняться немыслимым ранее делом: созданием собственных подразделений, занятых написанием программ под свои индивидуальные потребности. Но такой подход кроме массы плюсов имеет ряд минусов. Один из них заключается в том, что у банкиров не было сил и времени на выстраивание внутри своих структур лучших практик безопасной разработки ПО (Secure Software Development LifeCycle, SSDLC) и других элементов цикла проектирования и сопровождения софта. Поэтому банкиры и их коллеги из других сфер, решившиеся на цифровую трансформацию своих бизнесов, невольно породили и обеспечили значительный рост такого направления аутсорсинга, как контроль качества ПО.
Мировой рынок: тестировщики в восторге
О том, что представляет собой мировой рынок тестирования ПО сегодня, можно судить по ежегодному специализированному исследованию «Word Quality Report 2015-2016», подготовленному Capgemini, одной из крупнейших в мире консалтинговой компанией в сфере менеджмента и информационных технологий из Франции в кооперации с американской Hewlett-Packard Enterprise.
Как видно из диаграммы, доля затрат на обеспечение контроля качества ПО и тестирование в общих IT-бюджетах растет на глазах и в 2015 году достигла показателя 35%. Учитывая, что объем IT-затрат в мировом финансовом секторе в прошлом году по данным IDC составил примерно 460 млрд долларов (480 млрд в 2016 году), получается (если брать в целом по рынку) 160 млрд. Сумма весьма внушительная. Разрабатывать программы, тестировать и внедрять их, похоже, становится гораздо выгоднее, чем заниматься собственно банкингом или страхованием.
Не будем утомлять читателей деталями этого глобального исследования. Только несколько выводов. Во-первых, в «продвинутых» банках, о которых много говорил президент Сбербанка Герман Греф, происходит трансформация статуса топ-менеджеров от IT-директора (CIO, «главного по IT») к Chief Digital Officer (CDO, «главного по данным») в полном соответствии с тезисами Марка Андриссена. Во-вторых, из-за критической зависимости от качества функционирования софта вовсю идет процесс отказа крупнейших мировых банков от аутсорсинга в чистом его виде в пользу гибридных моделей вплоть до инсорсинга, что прекрасно видно на примере того же Сбербанка и «Сбертеха». В-третьих, регуляторные нормы по открытию API банками приводят к серьезным рискам, идущим со стороны финтех-компаний, эксплуатирующих эти интерфейсы. а это значит, что контроль качества ПО для стартапов будет законодательно подтянут до уровня банков. Это плохая новость для финтех, но тестировщики от этого в восторге.
В России по-прежнему две беды
У нас в стране также проводятся аналогичные исследования состояния дел в рассматриваемой сфере. Одним из наиболее авторитетных из них считаются совместные анализы компаний «Перфоманс Лаб» и Cnews Analytics «Russia Quality Report».
Последнее показывает, что элементы цифровой трансформации, как правило, происходят в первую очередь там, где процесс принятия бизнес-решений основывается на анализе данных. «Б.О» уже обсуждал этот парадокс на своих конференциях. Квинтэссенций таких дискуссий применительно к российским условиям можно назвать слова Вячеслава Семенихина, Global Marketing Officer, на одной из них: «В банках сейчас очень мало людей, умеющих считать. Зато есть огромное количество менеджеров, проходящих мимо любой инновации, но, тем не менее, ежедневно принимающих управленческие решения. Не редкость и такие совещания, когда после многомесячных переговоров с поставщиками данных эти менеджеры, вертя в руках диаграммы и графики, в которых ничего не понимают, принимают решения со словами: “Ну кто из этих троих вам больше нравится?”». К счастью, не все банки и МФО «заселены» подобными управленцами, есть много противоположных примеров.
Однако вернемся к данным свежего «Russia Quality Report 2015-16». Алена Горшкова, заместитель генерального директора «Перфоманс Лаб», указывает в отчете: «С точки зрения процессов обеспечения качества ПО банковскую отрасль можно назвать одной из самых зрелых в России. На постоянной основе тестирование проводится в 56% финансовых предприятий, а управление им происходит централизованно». С одной стороны, можно гордиться, а с другой — денег нет, специалистов тоже.
В этом исследовании в рамках репрезентативной выборки были опрошены 274 компании, среди них чуть меньше половины (41%) — банки и страховые компании. Исследователи отмечают, что в текущих условиях именно в банках по-прежнему сосредоточен достаточно большой объем собственной разработки и сохраняются большие IT-отделы. Именно в банках самая большая доля IT-бюджета тратится на контроль качества, а к результатам тестирования предъявляются наиболее высокие требования.
Финансисты имеют и самый высокий процент наличия центров компетенций по тестированию и планов по их созданию в ближайшее время, что не может не свидетельствовать о том, что банки уже успели оценить преимущества от внедрения этих центров, а также о высоком уровне зрелости процессов тестирования в данной отрасли.
При привлечении внешнего подрядчика банки стараются использовать модель «fixed price» и сервисный контракт, что позволяет за фиксированную стоимость получить заранее определенный результат. Только 24% респондентов работают по схеме «time and material», то есть оплачивают фактические трудозатраты.
Что и зачем тестируют в банках
В «Russia Quality Report 2015-16» утверждается, что тестирование проводится на всех этапах жизненного цикла разработки программного обеспечения. При этом чаще всего оно осуществляется на этапе внедрения продукта из соображений экономии. Однако такая тактика приводит к тому, что цена ошибки возрастает, поэтому в перспективе время тестирования, вероятно, будет смещаться к этапам формирования требований и разработки.
Само же качество тестирования в банковском секторе измеряется не только количеством найденных дефектов, но и другими критериями, например, сокращением потерь за счет предупреждения ошибок или сокращением времени выпуска программных продуктов.
Павел Эйделанд, руководитель центра тестирования компании «Аплана», делится своими соображениями: «Говоря о спектре тестируемых систем, можно отметить, что уровень зрелости компаний из разных отраслей повышается, поэтому ко все большему количеству организаций приходит осознание необходимости тестирования новых классов систем. Но локомотивом в этой части по-прежнему выступает финансовая сфера. Даже в IT-компаниях зачастую к тестированию относятся более вольно, чем в финансовых структурах: крупных банках, биржах и других организациях».
При этом участники рынка уверены, что нельзя говорить о том, что это направление меняется в отрыве от всей остальной IT-сферы: что происходит в целом по отрасли, то передается и в тестирование. «Например, растет доля мобильных приложений, «тонкие» клиенты почти вытеснили «толстых» (как следствие развития кроссбраузерного тестирования), происходит смена технологий в программировании (меняются языки и платформы), вводятся новые подходы к управлению проектами. Все это находит отражение и в области тестирования программного обеспечения», — добавляет аналитик.
Mobile и юзабилити тоже требуют тестирования
Вернемся к «Russia Quality Report 2015-16»: в современном мире удобный и функциональный мобильный банк становится весомым преимуществом в конкурентной финансовой среде, а также лакмусовой бумажкой качества предоставляемого предприятием сервиса. Неудивительно, что 87% участников опроса осуществляют тестирование своих мобильных приложений. Оставшиеся 13% в большинстве своем планируют это сделать.
Но тут есть несколько тонких моментов. Во-первых, в большинстве банков (57%) отсутствуют квалифицированные специалисты для проведения тестирования таких сервисов. Во-вторых, поскольку приложения рассчитаны на большой пул мобильных устройств, сложно обзавестись необходимым количеством тестовых сред.
Вероятно, это приведет к тому, что банки начнут прибегать к услугам организаций, предоставляющих мобильные устройства, или же перейдут на внешнее тестирование приложений, возможно, с привлечением конечных пользователей. Также можно прогнозировать, что широкое применение получит автоматизированное тестирование мобильных приложений. Оно позволит расширить покрытие платформ и как следствие сократит общие затраты. Кроме того, для таких приложений актуальны тесты безопасности и юзабилити сервисов.
Что касается юзабилити и дизайна, то иногда возникает вопрос: почему это относится к софтвернму компоненту, а не к промышленной эргономике, скажем? Да, были такие споры. Но сейчас большинство соглашается с Марком Андриссеном: «Даже дизайнеры становятся хорошими CEO — взгляните на Airbnb. Они всю компанию создали, думая в терминах дизайна. Дизайн стал чрезвычайно важен. Успех к Apple пришел не благодаря их железу. Он пришел из-за OS X и iOS. Дизайн находится в верхнем слое всего этого. Ходит множество разговоров о внутренней аппаратной красоте, но пресса это не печатает. Лучшие дизайнеры ориентированы на ПО, это те, кто понимает устройство софта на очень глубинном уровне. И разговор здесь не о поверхностной эстетике».
Облака для тестировщиков
Перечисленные выше сложности отечественные банкиры не прочь решить с помощью облачных вычислений. Поэтому тренд тестирования в облачной среде банки не обошел: 69% респондентов используют облачные технологии. При этом при выборе конкретного сервиса организации уделяют особое внимание безопасности данных (50%) и требованиям к пиковым нагрузкам (44%). Все участники опроса из финансовой отрасли обезличивают данные в облаке для тестирования. Михаил Бараблин, руководитель проектов компании AT Consulting, комментирует выводы аналитиков: «В ближайшем будущем банкиры не будут задумываться об актуальности использования облаков, тестирования точно будут проходить именно в них. Но возникнут другие вопросы. Во-первых, насколько быстро произойдет переход, ждать ли нам два года или пять лет? Во-вторых, какие банковские системы и процессы можно держать в публичных облаках, а каким лучше храниться в закрытых частных облаках непосредственно в самом банке? Вопрос с безопасностью на данный момент является открытым, так как не существует моделей безопасности, которые бы точно определили уровень защиты данных, поэтому пока что в облачные инфраструктуры помещают только системы без продуктивных данных, связанных с клиентами».
В перспективе следует ожидать, что банки и страховые компании будут выносить отделы тестирования и разработки из своих центральных офисов, а также, перейдя на проектную деятельность, скорее всего, будут запрашивать внешние ресурсы на проведение тестирования. В этом есть некоторое отличие от их западных коллег.
Приводит свое мнение и Павел Эйделанд: «Не могу отметить каких-то кардинальных различий в тестировании ПО в облаке и программных решений, развернутых локально. Есть только несколько особенностей. Первая — это особенности сети: серверы расположены в облаке и могут взаимодействовать с другими системами не через локальную сеть, а через Интернет. Особенно важны такие аспекты при проведении нагрузочного тестирования, и вдвойне важно, когда стенд в облаке выделяют только для тестирования, тогда как в промышленной эксплуатации система будет работать на «железных» серверах. Кроме того, есть особенности расширения пула серверов в облаке, наложения некоторых эффектов от разных платформ виртуализации. С точки зрения функционального тестирования различий практически нет».
Жизненный цикл ПО банке. Тень Франкенштейна
Ни в коем случае, говоря о контроле качестве ПО, нельзя ограничиваться классическими методами тестов. Это понятие гораздо шире, в него входят и управление жизненным циклом приложений, и ведение дефектов. Какие решения для этого используются в российских банках? Михаил Бараблин делится своим опытом: «В тех банках, с которыми работает AT Consulting, процесс тестирования строго определен, обычно программный продукт проходит до шести тестовых сред. Этой же процедуре подвергаются даже части самого кода. В целом, в большинстве банков 90% тестирования происходит вручную, для всего остального (автоматизированного тестирования или тестирования на фокус-группах) существуют строгие регламенты».
Такое количество уровней негативно отражается на времени реализации, поэтому сейчас принято сегментировать программное обеспечение, и к некритически важным программным продуктам, например, к лендинг-страницам, применять более мягкие модели тестирования, что позволяет сокращать время вывода продукта. Отчасти этой причиной обусловлен переход к облачным технологиям, так как они позволяют упростить развертывание инфраструктуры.
А каким образом контролируется качество ПО в банках? Каким образом оно тестируется? Сейчас на рынке представлено достаточно много различных средств для управления тестированием: это и платные инструменты от крупных корпораций, и Open Source-решения, и коммерческие разработки от небольших компаний.
«Не хотелось бы заниматься рекламой или антирекламой, могу сказать лишь, что текущие тренды в этой области — это заимствование лучших решений или интеграция с ними. Например, некоторые крупные компании видят, что на рынке автоматизации тестирования успешно развивается Open Source-решение Selenium. Их реакция вполне логична — они объявляют, что в их платных продуктах есть интеграция с этим популярным средством. Аналогичные события происходят и в других областях тестирования», — считает представитель «Апланы».
Однако, несмотря на разнообразие инструментов на рынке, на нем присутствует крайне мало решений для управления полным циклом: от требований до инцидентов. Все попытки сделать какое-то универсальное решение от одного вендора, на мой взгляд, пока приводят только к созданию неких «Франкенштейнов», у которых выпячиваются те блоки, на которых специализировался производитель: оно удобно либо для разработчика, либо для тестировщика, либо для руководителя проектов. Достойных примеров того, чтобы всем было хорошо, пока крайне мало.
А судьи кто?
Как банки оценивают эффективность самих проектов по тестированию? Очевидными критериями, по данным «Перфоманс Лаб» и Cnews, являются количество найденных и пропущенных дефектов, а также процент покрытия требований. Но есть и своя специфика: 41% участников опроса обращают внимание на снижение показателя «time to market», 36% — на сокращение потерь за счет предупреждения ошибок. В «Аплане» считают, что здесь все-таки необходимо уточнить терминологию: оценивать эффективность проектов или работающего процесса тестирования? Если говорить о проектах, то у каждого из них своя цель, и отталкиваться нужно именно от этого. Целью может быть как нахождение предела производительности системы (для нагрузочного тестирования), так и уменьшение сроков проведения регрессионного тестирования (для автоматизированного тестирования), ну и, конечно, поиск дефектов перед внедрением.
Если же мы говорим о процессе контроля качества, который принято называть тестированием, то его цели и эффективность можно оценивать по тому, насколько качественный продукт попадает в промышленную эксплуатацию. При этом важно понимать, что если после тестирования одной системы в промышленной эксплуатации обнаруживается одна ошибка, а после тестирования второй системы — 10 ошибок, то это не значит, что во втором случае процесс работает хуже.
«Процесс контроля качества только предоставляет информацию о том, насколько качественным является продукт. Но есть более широкий процесс — обеспечение качества, в который входят и разработка, и анализ, и руководство проектами, и планирование в более широком смысле. Если же вы все-таки хотите узнать, насколько хорошо у вас работает тестирование, то проще всего измерить отношение числа найденных во время тестирования ошибок к числу ошибок во время промышленной эксплуатации, а также общее количество ошибок в «проме». Если в эксплуатации нет критичных ошибок, а общее соотношение 1/20 и меньше, то тестирование, скорее всего, работает хорошо, но, конечно, к каждому случаю необходимо подходить индивидуально и анализировать все факторы, которые приводят к ошибкам», — ставит точку Павел Эйделанд.
Тестирование ПО или его…доказательство?
Не только банки испытывают давление со стороны финтеха. Научный прогресс пришел и в эту сферу человеческой деятельности. Поэтому даже умудренные опытом тестировщики с тревогой поглядывают на стартапы, особенно если в основе их идей лежат фундаментальные научно-технические изыскания.
Сегодня начинают появляться стартапы, призванные изменить ситуацию и привнести технологии сертифицированного программирования «в массы», сделав их использование простым и комфортным. Таковым является, например, российский проект FinProof, приступивший к созданию инфраструктуры для массового применения таких технологий в финансовой сфере, где программные ошибки иногда обходятся в десятки и сотни миллионов долларов. Яркий, можно сказать, провоцирующий питч все желающие могли услышать 28 июня 2016 года на конференции финтех Lab 2016, организованной порталом bankir.ru. Справедливости ради надо отметить, что у этого проекта и есть некие аналоги, например, команда Imandra — тоже крайне любопытное явление в области банковского софтверного хайтека.
О чем, собственно, идет речь? Традиционно тестирование программных продуктов упрощенно выглядит следующим образом: как указывалось выше, разработчики пишут код, а тестировщики (часто — сами программисты) разрабатывают тесты, пытаясь покрыть максимальный объем сценариев, по которым будет выполняться программа. Проблема в том, что протестировать все мыслимые сценарии крайне сложно и дорого, позволить себе такое могут только такие организации, как NASA (да и то с серьезными оговорками), а большинство вполне серьезных и уважаемых банков удовлетворяется покрытием в 70–80%.
«Это значит, что 20–30% сценариев вообще не проверяется, что, впрочем, вполне достаточно для большинства практических применений. Однако в тех случаях, когда закравшаяся ошибка может привести к крупным финансовым потерям, провалу проекта, который готовился несколько, лет или, что еще хуже, к гибели людей, традиционное тестирование неспособно в полной мере гарантировать необходимую надежность программного кода», — утверждает Андрей Ля-шин из компании «Скайкон», сооучредителя FinProof. Поэтому в последние годы активно развиваются альтернативные методы верификации и проектирования программного кода, когда соответствие кода спецификации определяется способом, отличным от простого полного перебора тестовых сценариев (так называемые формальные методы и сертифицированное программирование).
Более того, развитие таких разделов математики, как теория типов, исчисление конструкций, а также строго типизированного функционального программирования позволило создать удивительные методы разработки, когда программа представляет собой строго математически доказанную теорему о том, что это программа полностью соответствует спецификации. «Грубо говоря, вы пишете программу, ее принимает верифицирующая программа-ассистент (аналог компилятора) и … все — ваша программа гарантированно работает правильно, вернее, полностью соответствует спецификации. После этого программу можно использовать как строго проверенный работающий модуль практически любой программной среды. Конечно, роковая ошибка может закрасться и в спецификацию, но вероятность такого события уменьшается в несколько раз. К тому же проверить спецификацию гораздо проще, для этого не требуется специальной квалификации программиста, по размеру она гораздо меньше и понятнее программного кода. По нашим оценкам, можно считать, что использование такого подхода уменьшает вероятность проявления критической ошибки в 4-5 раз», — утверждает Андрей Ляшин.
Указанный подход уже принимается на вооружение в мире. Так, с его помощью была автоматизирована 14-я линия Парижского метро, работающая без машинистов, американский авиастроительный гигант Lockheed Martin применял его в одной из последних модификаций военно-транспортного самолета Hercules, Microsoft активно пробует его в недрах своих лабораторий.
Поляна для отечественного финтеха
Стоит отметить, что многие ожидают внедрение этой технологии именно в тех секторах разработки программного обеспечения, где последствия ошибки несопоставимы с любыми затратами на ее исправление, а именно: транспорт, медицина, программные продукты космического и военного назначения и, без сомнения, финансы и финтех — одна из отраслей, наиболее активно развивающаяся в последние годы и в то же время содержащая критические программные модули.
Михаил Бараблин высказывает свое мнение: «Такие методы хороши для развития культуры программирования, но чаще всего баги в программах возникают не из-за использованных методов, а из-за человеческого фактора. Очень часто проблема заключается в отсутствии налаженной коммуникации между командами разработчиков на крупных проектах, поэтому, на мой взгляд, снизить количество ошибок можно, только обеспечив прозрачность информационного поля и организовав эффективное общение между организационными единицами».
Напрашивается логичный вопрос: что мешает применять эту замечательную технологию в отечественных банках? Основные проблемы здесь — высокий порог вхождения (на настоящий момент это действительно сложно для использования) и отсутствие необходимой инфраструктуры (готовых модулей, библиотек, сред разработки и т.п.). Если первая проблема постепенно теряет свою актуальность по причине того, что функциональное программирование, владение которым необходимо для использования подобных технологий, начинает становиться не экзотической диковинкой, а практически обязательным навыком любого программиста даже не очень высокой квалификации, то вторая проблема на сегодняшний день не решена.
Однако, если искать у банкиров и страховщиков места, где есть нерешенные проблемы, этот материал можно не закончить никогда. И, если они сами не очень-то готовы их решать, значит, это та самая поляна, где российский финтех будет востребован еще очень долго.
Делая выводы, необходимо признать: если раньше банкиры боролись со сложностью своего бюрократического аппарата и регуляторных требований, то нынче им приходится сталкиваться с колоссальным объемом строк того ПО, от которого зависит, будет ли бизнес процветать или случится неожиданный disruption. Исключить последнего нельзя, а вот минимизировать его вероятность можно. Хочется того или не хочется, придется двигаться в сторону неизведанных до сих пор сфер, или финтех «придет и съест наш ланч».