Тестирование ПО: спрос растет

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

Любые внедряемые системы должны быть протестированы - иначе это потеря времени, настроения, денег. "Если вы пишите системы для себя – требования можно понизить, – говорит Александр Забродский, начальник отдела разработки и поддержки информационных систем "Группы Гута". – Системы, которые пишутся своими силами, должны быть протестированы хотя бы вручную (blackbox testing). Причем как на этапе окончания разработки, так и на этапе каждой доработки. Если продукт большой и есть время, то стоит вести разработку с использованием Unit-тестов, а еще лучше подойти к разработке через TDD (разработка через тестирование ). Впоследствии это сэкономит время".

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

Любое изменение должно тестироваться, причем во время тестирования должны быть проверены все узлы программно-аппаратного комплекса. Татьяна Тихонова, начальник отдела тестирования компании "Форс", перечисляет некоторые из них: "Это быстродействие приложения при различных нагрузках, загрузка ресурсов клиентских мест, серверов приложений и баз данных, нагрузка на сеть. Сроки различны и составляют от недели до нескольких месяцев в зависимости от количества необходимых итераций, сложности функционала и того, что хочет видеть заказчик. После каждого внесения патчей требуется проведение тестирования сначала на серверах разработчика, а потом – на серверных мощностях заказчика. Это может выполняться и в рамках опытной эксплуатации. Таким образом, сколько развивается система, столько она будет тестироваться". Подход максималиста, который требует немалых ресурсов и затрат. В жизни, конечно, все гораздо проще.

Руслан Шарипов, заместитель руководителя департамента организационных процессов и ИТ-инфраструктуры компании "Парма-Телеком" считает, что системы должны подвергаться тестированию в следующих случаях: во-первых, внесение изменений из-за необходимости устранения обнаруженных в ходе эксплуатации ошибок и недочетов, доработки и модернизации продукта по требованию заказчика, изменившихся внешних условий (например, увеличения числа пользователей, объема хранимой и обрабатываемой информации), обновления версии ПО. Осуществляется по факту инициации внесения изменений. Во-вторых, при проверке функционирования системы на предмет соответствия своим паспортным данным и спецификациям в части производительности, надежности, доступности (например, замер времени отклика). Тестирование должно осуществляться на регулярной основе и на "боевой" системе. В-третьих, внедрение системы с целью выбора наиболее оптимального аппаратного обеспечения с точки зрения скорости работы. Системы, подлежащие внедрению, которые имеют в качестве критерия успешности быстродействие, и при этом не ограничены заказчиком при выборе оборудования, должны проходить процедуру тестирования на различных аппаратных платформах, поддерживаемых внедряемым ПО. За исключением случаев, когда для внедряемого ПО уже существуют результаты замеров производительности (benchmarking)  от независимых и заслуживающих доверие экспертов.

При этом тестирование должно производиться не только на этапе разработки или внедрения (в случае "коробочных" систем), но и при внесении изменений в уже внедренные системы. Михаил Брантов, руководитель группы управления качеством ПО управления информационных технологий "Райффайзенбанка", заявляет, что при этом тестированию должны подвергаться не только изменения системы, но и тот функционал, что был внедрен ранее. Это необходимо для того, чтобы удостовериться в том, что изменения части системы не повлияли на работу системы в целом.

Проверить, правильно ли работает система, когда ей предоставляют правильные исходные данные – это половина дела. "Часто пользователи делают совсем не то, что ожидали от них разработчики. И система должна быть "дуракоустойчивой", корректно реагировать на самые странные запросы. Не "падать", когда ее просят поделить на ноль, и т.п. Также, кроме неискушенных пользователей, есть еще и хакеры, специально старающиеся сломать систему. И большинство успешных атак происходит именно за счет того, что системе предоставили исходные данные, которых она вовсе не ожидала", – поясняет Антон Разумов, руководитель группы консультантов по безопасности Check Point Software Technologies.

Тестирование по правилам

В качестве основных этапов испытаний Сергей Тихомиров, руководитель направления "Финансовые институты" группы компаний Custis,выделяет следующие: сначала функциональные испытания – их суть в проверке новой версии системы на соответствие функциональным требованиям, которые согласуются для данной версии. Следующий шаг: испытания интеграционного контура системы на предмет взаимодействия внедряемой системы с существующими системами в организации. "Это очень важный этап, так как на текущий момент практически в любой крупной организации существует свой ИТ-ландшафт, а интеграция становится все более сложной и важной задачей", – уточняет он. И, наконец, испытания функционирования совокупности систем, в которую входит внедряемая система. "На данном этапе крайне важно участие пользователей, так как в любом сложном внедрении нельзя предусмотреть всего. После указанного набора мероприятий новую версию системы можно вводить в тестовую эксплуатацию", – рекомендует Сергей Тихомиров.

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

Из рекомендаций видно, что правильная организация тестирования – очень непростой процесс. Мало того, на проекте внедрения он может вылиться в большие затраты. "Придется тестировать программное решение на платформах от трех ведущих производителей вычислительного оборудования. Они отличаются не столько брендом, сколько архитектурой вычислений: Intel (вендор роли не играет), IBM Power, Oracle/Sun Microsystems SPARC (предполагается, что тестируемая система поддерживает все три платформы). Добавьте сюда системы хранения данных от EMC, IBM, Oracle, Hitachi и получите спецификацию полигона, сравнимую по стоимости с небольшим ЦОДом", – комментирует Руслан Шарипов. Алексей Добровольский, директор по разработке ПО компании "Крок" отмечает, что существенных затрат может потребовать не только само тестирование, но и оборудование, лицензии (ведь ПО и на тестовых стендах должно быть правильным образом лицензировано), поддержка тестовой среды.

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

Оценка альтернатив

В последние год-два компании активно идут по "облачному" пути. "Выгода очевидна: не нужно платить за простаивающее 99% времени оборудование, можно буквально за минуты (при наличии заранее готовых образов) развернуть тестовую среду любой сложности и конфигурации. Если, например, стоимость необходимого оборудования и проведения нагрузочного теста системы документооборота на 15 тыс. пользователей составит от нескольких сотен тысяч до нескольких миллионов долларов, то в "облаке" проведение одного теста обойдется в $1000–2000 – благодаря отсутствию необходимости закупать элементы этой системы", – оценивает эффективность такого подхода Алексей Добровольский.

В вопросе привлечения сторонних специалистов мнения экспертов разделились. Александр Забродский считает, что зачастую локальный тестировщик не может проверить все кейсы, просто не успевает, а для нагрузочного тестирования либо не хватает знаний и времени, либо приходится закупать специальный софт – например, HP Quality Center, HP Quick Test Professional, Visual Studio Test Professional. Специализированная компания с такими проблемами не столкнется. Кроме того, поставщик оборудования зачастую может предложить несколько вариантов конфигурации, предоставить оборудование, подготовить сценарии тестирования и провести его профессионально. А новые классы АПК порой можно посмотреть и протестировать только у поставщиков в специализированных демо-центрах. К примеру, в России полную линейку продуктов Oracle Engineered Systems можно посмотреть только в инжиниринговом центре FORS ExaStack Studio.

Конечно, существует и противоположное мнение. "Обращаться к официальному представителю вендора ПО необходимо, чтобы получить список рекомендуемого АО, при использовании которого гарантирована отказоустойчивость. Сторонний тестировщик может быть полезен, если имеет опыт развертывания системы в конкретной программно-аппаратной конфигурации, – перечисляет Глеб Петров, руководитель отдела разработки новых продуктов группы компаний Maykor. – Но наиболее правильный путь к успеху – наращивание компетенций внутри компании и формирование собственных списков совместимости на базе приобретенного опыта".