О контроле качества ИТ-систем на примере собственной российской практики обозревателю PC Week/RE Сергею Бобровскому рассказывают Виктор Вайнштейн, генеральный директор компании “Аплана”, и Пётр Можаев, руководитель Центра контроля качества “Апланы”.

PC Week: Как ваш бизнес связан с контролем качества ИТ-систем?

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

Термин “организация разработки и контроль качества информационных систем” распадается на две составляющие. Первая — консалтинговая. При наличии у заказчика действующего внутреннего центра разработки или планов по его созданию мы помогаем настроить его работу либо создать такой центр с нуля. Внутренние центры разработки часто действуют в компаниях, которые активно используют информационные системы в своей деятельности и не менее активно развивают функционал этих систем. Примером является Сбербанк, где мы создали Фабрику разработки АБС, помогли специалистам банка настроить процессы, связанные с разработкой, и внедрили инструменты из линейки IBM Rational Jazz.

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

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

PC Week: Вы сами разрабатываете софт?

В. В.: У нас есть блок заказной разработки, который близок остальным направлениям деятельности с точки зрения организации производственного процесса, но отличается от них с точки зрения продаж, потому что продавать заказчику и контроль качества, и разработку “в одном флаконе” довольно странно. Это несколько антагонистичные бизнесы. По крайней мере то, что мы разрабатываем, мы, конечно, тестируем, но продавать заказчику этот сервис — тестирование того, что мы разработали, — было бы довольно странно.

PC Week: Какие технологии разработки вы используете?

Пётр Можаев: В большинстве случае Java, реже .NET. Это касается как разработки серверных компонентов информационных систем, так и клиентских рабочих мест. Если говорить о разработке Web-приложений, то тут в основном используется Java.

PC Week: В каких примерно пропорциях по этим четырём направлениям распределяется ваш доход?

В. В.: Консалтинг занимает около 20%, а контроль качества и разработка — в равных долях по 40%.

PC Week: Меняются ли эти пропорции со временем?

В. В.: Все эти направления достаточно активно развиваются. На нашем рынке образуется очень интересный сегмент “систем массового обслуживания”. Цена ошибки в подобных системах очень высока, потому что ими пользуется огромное количество клиентов. Это может быть онлайн-банкинг, торговая система, интернет-магазин, телеком-система, биллинг и т. п. Если такая система перестанет работать, будет очень плохо. А взять её полностью в протестированном и готовом виде провайдеру практически невозможно, потому что серьёзные клиенты всегда делают предложение, адаптированное с маркетинговой точки зрения, — чем-то отличающееся от конкурентов. То есть идет процесс диверсификации предложений, в том числе и за счет функциональности информационной системы. А там, где происходит “кастомизация”, обычно возникают разные проблемы, и наша задача — поймать эти проблемы до момента, когда система поступает в промышленную эксплуатацию. Это прямой бизнес-кейс по экономии средств для заказчика, который тратит немного больше денег на начальном этапе, правильно делая масштабирование, выполняя функциональное тестирование, зато на этапе промышленной эксплуатации не имеет проблем, которые “транслируются” на клиентов и требуют больших средств для ликвидации последствий такого рода ошибок.

А заказная разработка развивается потому, что диверсификация предложений, лидерство в каком-то сегменте рынка достигаются клиентами и за счёт качества. Можно пойти на рынок и взять готовую систему, но точно такая же уже установлена у большого количества клиентов, и здесь нет какой-то особенной “значимости”. Уникальность достигается за счет каких-то идей из бизнеса, переложенных в функциональность информационной системы. И здесь вступает в действие заказная разработка. Её могут делать вендоры, но во многих случаях мы занимаемся либо интеграцией, либо такими системами, которые не существуют, или такими, которые лицензионно невыгодно покупать в виде продуктов, а выгоднее разработать под потребности конкретного заказчика — и таким образом получить либо какую-то конкурентную выгоду, либо снижение издержек.

PC Week: Как вы находите заказчиков под задачи контроля качества? Это всё же вещь достаточно специфическая.

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

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

П. М.: Исторически сложилось так, что в России услуги внешнего (стороннего или аутсорсингового) тестирования информационных систем отстают от Запада, где специализация усилилась, но сейчас всё больше компаний начинают понимать, что за отдельный сервис надо платить. Если вы хотите добиться более высокого качества и лучшей организации производства программного обеспечения, тогда необходимо привлекать профессиональные компании, которые этим занимаются.

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

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

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

PC Week: С какой точностью вам удаётся укладываться в проектные сроки тестирования?

П. М.: Поскольку тестирование является зависимым сервисом (мы не можем начать его до тех пор, пока, грубо говоря, не разработана система, которую мы будем тестировать), то сроки во многом зависят не от нас. Если говорить о сроках именно тестирования, то более чем в 95% случаев мы их выдерживаем. Но само время проведения тестирования при этом, разумеется, двигается. Если разработчик говорит, что, скажем, к пятому марта система будет готова для тестирования, а по факту она готова лишь к десятому числу, то происходит сдвиг общих сроков выполнения проекта, даже если сроки проведения тестирования соблюдены.

PC Week: В чем сейчас главные проблемы в конкретных проектах по тестированию?

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

PC Week: В последнее время стал распространённым переход в облачные технологии, в мобильную сферу…

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

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

PC Week: Вы применяете в своей деятельности гибкие подходы?

В. В.: Да, но пока их доля не превышает 20%. Я могу объяснить одну из причин, почему Agile плохо прививается в России. Сущность Agile-методик заключается в том, что в оговоренный срок с оговоренным бюджетом поставщик представляет версию максимально достижимого качества. Потому что идут итерации, и каждая итерация делается на основании некоего набора требований, которые в неё могут попадать. И всё это очень гибко двигается между итерациями. Но заказчик в России привык, что у него есть техническое задание и оно должно быть реализовано. И заказчику не очень комфортна мысль, что он может заплатить деньги, но не получить 100%-ной реализации ТЗ, то есть не все требования будут выполнены или какие-то из них будут выполнены не полно.

Поэтому здесь нужен очень серьёзный уровень доверия между заказчиком и исполнителем. В гибкой модели этого достичь трудно. Но как только заказчики поймут, что они получают предсказуемый срок и предсказуемый бюджет — я думаю, что это направление потихонечку начнет сдвигаться. Кроме того, Agile очень плохо ложится на современную контрактную систему. Например, в госуправлении его вообще в текущей модели реализовать невозможно.

П. М.: Поскольку мы в большей степени ориентируемся на сегмент среднего и крупного корпоративного бизнеса, то в 80% случаев используем IBM RUP и построенные на его базе методологии. К сожалению, Agile в данном сегменте и в госсекторе на сегодняшнем этапе малоприменим, а RUP понятен и прост — проще разбить проект на чёткие и понятные этапы, и проще такие проекты финансировать.

PC Week: Спасибо за беседу.