«СберТех»: «Аплану» отличает чёткое решение кадровых вопросов

Один из ключевых сотрудников, с которым взаимодействуют наши специалисты на проектах Сбербанка - Антон Тельнов, начальник отдела тестирования компании «Сбербанк-Технологии».

«СберТех»: «Аплану» отличает чёткое решение кадровых вопросовОдин из ключевых сотрудников, с которым взаимодействуют наши специалисты на проектах Сбербанка - Антон Тельнов, начальник отдела тестирования компании «Сбербанк-Технологии».


— Антон, расскажите о настоящем вашего отдела. Какова его структура и какие задачи он решает?

Меня зовут Антон Тельнов. В компании Сбербанк Технологии я занимаю позицию начальника отдела тестирования биллинговых технологий Департамента Качества. До СБТ я работал в крупнейших банках России: МТС-Банк, Райффайзенбанк, и вот уже более 2-х лет я работаю в компании СБТ.

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

Единая платежная система — это система, через которую проходят все платежи во всех территориальных банках России. АС ЕПС пришла на замену более чем 10 биллинговых систем, работавших автономно в каждом тер.банке. В рамках проекта «Миграция локальных биллингов» было принято решение централизовать платежную систему и вывести из эксплуатации локальные биллинговые системы. Это позволило пользователям по всей России получить единый платежный интерфейс, улучшить поддержку и безопасность системы, повысить качество и надежность и гарантировать получение платежа поставщику услуг в заявленный срок в 99,99% случаев.

ЕПС в рейтинге департамента качества признана самым сложным из находящихся в промышленной эксплуатации решений. Во-первых, она интегрирована с очень большим количеством систем. Во-вторых, система должна работать в режиме 24x7. Простой даже на минуту может повлечь репутационные и финансовые риски Банку. Для нашего коллектива поддержка стабильной работы данной системы — это вызов.

Именно поэтому в отделе работает более 50 высококлассных специалистов по тестированию. Все тестировщики – являются выпускниками ведущих технических ВУЗов Москвы, Санкт-Петербурга и Самары. Большинство специалистов ранее работали в крупных иностранных и российских компаниях с хорошо выстроенными процессами. Их опыт и знания помогли нам выстроить бесперебойный процесс тестирования и выдержать требования к качеству и надежности системы АС ЕПС.

Также в отделе выполняется тестирование таких критичных систем, как «Сбор Данных» и «Стоп-лист». Соответственно, данные системы отвечают за сбор информации по кредитным обязательствам и хранение данных о злостных неплательщиках, террористах и прочих неблагонадёжных категориях людей.  Ещё один важный участок — тестирование АС «Инфобанк», через которую осуществляется перевод средств и управление ценными бумагами Сбербанка.

Набирает обороты тестирование систем на платформе поддержки развития бизнеса (ППРБ). Данная платформа позволит унифицировать интерфейс разработки для большинства бэк-офисных систем Банка и перейти к микросервисной инфраструктуре. В отделе тестируются следующие системы «ППРБ Переводы», «ППРБ Контроль обработки операций», «ППРБ Стоп-лист». Также вскоре мы начнём работу над системой «ППРБ Платежи».

— Сбербанк и «СберТех» традиционно много внимания уделяют инновациям. Какие современные инструменты и методики взял на вооружение ваш департамент в последнее время?

— Главной задачей департамента качества в 2016 году стало внедрение методологии DevOps, которая стала активно использоваться 2016 г. как в рамках отдела, так и во всём департаменте качества и даже в некоторых подразделениях сопровождения. DevOps призвана ускорить сборку ПО, вывод его в эксплуатацию и предполагает достаточно плотное взаимодействие программистов, тестировщиков и других участников команды при создании продуктов.

Мы начали с того, что проанализировали архитектурные особенности практически всех наших legacy-систем на предмет пригодности. Сотрудничая с разработкой, мы добились вывода решения, которое позволяет осуществлять сборку целиком и автоматически ее устанавливать на стенде тестирования. Например, подобное решение реализовано для систем на платформе IBSO. Сейчас мы можем в автоматическом режиме размещать его на тестовом стенде. Также наша команда разработала ряд автотестов, используя различные технологии и фреймворки.  Уже проделан довольно большой объем работ, но сделать предстоит ещё больше. На сегодня мы находимся на стыке интеграционного функционального тестирования и приёмо-сдаточных испытаний.

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

Новый подход был опробован уже на двух квартальных релизах. В результате удалось примерно на 30% сократить сдвиги передачи доработок с этапа тестирования на этап приёмо-сдаточных испытаний.

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

Для создания автотестов у нас используются такие инструменты, как Java, Selenium, Cucumber. Также на основе HP UFT мы реализовали фреймворк для систем, которые не имеют веб-интерфейса, а открываются через «толстый клиент» — это прежде всего десктопные приложения.  Запуск тестов производится с помощью инструмента Jenkins (позволяет выполнять автосборку, автоустановку на тестовый стенд и автоматический запуск тестовых сценариев). Для управления процессом тестирования служат системы HP ALM, IBM Rational Jazz. Управление задачами в основном производится с помощью Jira. Это целевой набор инструментов, который используется практически везде, но иногда бывают исключения – всё зависит от специфики систем, которые мы тестируем.

— Какие изменения произошли у вас в области тестирования в последнее время?

Бизнес-заказчик принимает активное участие в тестировании, он заинтересован в том, чтобы команда тестирования периодически проводила демонстрацию функционала. Таким образом, можно быстрее проводить приёмо-сдаточные испытания и ещё на этапе интеграционного тестирования выявлять проблемы, высказывать замечания и вносить коррективы. Как и вся компания «Сбербанк-Технологии», мы идём в сторону методологии разработки Agile. Благодаря этому мы каждые две-три недели сможем демонстрировать бизнесу промежуточные версии продукта.

— Со сколькими компаниями по обеспечению качества ПО вы сотрудничаете? Какие ключевые требования «СберТех» предъявляет к партнерам в области QA?

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

Основные требования к партнёрам

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

— По вашему опыту, каковы основные условия успешного проекта по тестированию с участием аутсорсера?

— Кардинальных отличий у крупных игроков рынка тестирования сегодня практически нет, разница, как правило, в опыте работы по тому или иному направлению. Но если требуется протестировать какую-либо новую систему, при выборе специалистов на первый план выходит профессиональный уровень. Так, у себя в отделе я не разграничиваю сотрудников на штатных и работающих в компании-подрядчике. У нас культивируется принцип командной работы, а ключевым фактором мы считаем увлечённость проектом. Если специалист подрядчика мотивирован (что называется, у него «горят глаза»), ему нравится проект и интересно находить ошибки, то даже без большого опыта в тестировании и высокой технической квалификации он сможет успешно выполнить работу.

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

— Как отличить действительно классную команду тестированию, которая стремится обеспечить клиенту действительно качественный продукт, от обычных «заводильщиков багов»?

— В хорошей команде всегда должны быть технические эксперты, к которым можно обратиться за советом. В идеале команда на 15-20% должна состоять из специалистов в области автоматизации, платформ, бизнеса. Также необходим тест-менеджер, который хорошо умеет выстраивать процессы, обладает развитыми коммуникационными навыками и может грамотно организовать работу команды и её взаимодействие с группой разработки и с заказчиком. Соответственно, от экспертной части команды обязательно требуются различные сертификаты, наличие опыта в аналогичных сферах деятельности. Как правило, к рядовым инженерам-тестировщикам нет жёстких требований, им достаточно иметь опыт работы 1-2 года. А для стажёров главное - это интерес к проекту и желание развиваться, опыт здесь не принципиален.

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

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

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