Начальник отдела сопровождения жизненного цикла программного обеспечения ВТБ Иван ДМИТРИЕВ В начале года в ВТБ внедрили уникальную систему автоматизированного тестирования, которая позволяет выявлять дефекты в интеграционной платформе на ранних стадиях запуска проекта и точно локализовать их. О том, какие преимущества и особенности в использовании имеет данный инструмент, НБЖ рассказал начальник отдела сопровождения жизненного цикла программного обеспечения ВТБ Иван ДМИТРИЕВ

- ВТБ уже на протяжении нескольких лет плотно сотрудничает с компанией «Синимекс». Какие проекты были реализованы в банке за этот период?

- Действительно, наше сотрудничество продолжается около четырех лет. И в течение этого времени мы ежегодно реализовывали какие-нибудь крупные проекты в сфере автоматизации деятельности по контролю процессов. Так, в 2007 году в банке были внедрены средства для проведения регрессионного тестирования производительности одного из ключевых бизнес-процессов, затрагивающего систему расчетов, на базе инструмента Jmeter. Стоит отметить: несмотря на то, что прошло уже достаточно много времени (с точки зрения развития информационных технологий), данная разработка морально не устарела и активно используется отделом тестирования банка до сих пор. Затем, в 2008 году, была внедрена разработка автоматизированной тестовой модели для функционального тестирования АРМ «Операционист» (ввод клиентов, счетов, создание и обработка документов). Автоматизацию данного приложения усложнило то, что оно было разработано на базе MS Аccess. Для реализации поставленной задачи пришлось применять такой «серьезный» инструмент, как Rational Functional Tester.

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

В 2010 году мы начали работу по проведению ряда функциональных тестирований по внедряемым системам: по системе предкредитной обработки, АРМ «Позиционер» и т.д.

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

- Почему было принято решение внедрить систему автоматизированного тестирования?

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

- Какими функциональными особенностями обладает Cinimex Test Tool? Известно, что в банке используется несколько систем автоматизированного тестирования.

- Компания «Синимекс» оказывала банку различные услуги по автоматизации - тестовая модель автоматизировалась как на инструментах для функционального тестирования, таких как IBM RFT, HP QTP, так и на инструментах для тестирования производительности, например, Jmeter.

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

проверку работы с сообщениями JMC продукта IBM WebSphere MQ и веб-сервисов;
мониторинг изменений в базе данных;
взаимодействие с несколькими внешними системами одновременно;
создание собственных адаптеров к внешним системам.

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

- Если можно, расскажите подробнее о том, до какой степени может осуществляться детализация. По каким критериям определялись ее параметры?

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

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

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

- В каких блоках осуществляется автоматизированное тестирование?

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

- Покрывает ли этот инструмент все потребности по автоматизации тестирования программного обеспечения, или остаются еще неосвоенные "пространства"?

- Инструмент достаточно специфичен - он заточен на функциональное и нагрузочное тестирование интеграционных решений, используется для их компонентного либо интеграционного тестирования. Но он не «всемогущ». Этот инструмент, например, невозможно использовать для тестирования графических интерфейсов. Такая цель перед ним и не ставилась. На рынке достаточно инструментов для тестирования интерфейсов, и мы можем эффективно использовать их. Cinimex Test Tool заполнил нишу, которая ранее пустовала.

- Какова вероятность того, что тест не выявит ошибок в системе?

- Только в том случае, если данная ситуация не была продумана на этапе создания тестовой модели и какой-то вариант поведения системы не был покрыт тестовым сценарием.

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

- Что делать в том случае, если ошибка все-таки не будет выявлена на этапе тестирования?

- Тогда поиск ошибок и их исправление происходит «на ходу». Это, в конечном счете, может привести к определенным финансовым и имиджевым потерям. Например, может быть не проведен платеж вовремя.

- Тесты стандартные или для каждого случая существует индивидуальный их набор?

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

- Таким образом, библиотека тестов постоянно расширяется, тесты дописываются. Как систематизировать библиотеку?

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

Сами сьюты (тестовые наборы) формируются либо как проверка краткого (основной критичный функционал) или полного регресса, либо выделяются в скрипты для проверки какой-то конкретной функциональности.

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

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

При первичной автоматизации части тестов Cinimex Test Tool показал отличные результаты, поэтому было принято решение автоматизировать оставшуюся часть тестов и последующие тесты на нестандартные ошибки, которые затем включались в набор регрессионных тестовых сценариев. На первичную автоматизацию и внедрение в процесс тестов, покрывающих основной критичный функционал, потребовалось всего 1,5-2 недели.

- Каким образом осуществляется поддержка системы: кто пишет необходимые тесты на дефекты и проводит тестирование?

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

- Могут ли специалисты банка впоследствии самостоятельно обслуживать данную программу?

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

- Если говорить о далеких перспективах, то возможно ли, что банк в скором времени полностью перейдет на автоматизированное тестирование?

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

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

Беседовала Вероника Сошина

Источник
NBJ