Контакты

Артак Оганесян: Тестировщику полезно услышать крики пользователей

CNews - 31 октября 2011

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

Как эффективно выстроить взаимодействие с подрядчиком и оценить качество его работы? Способна ли новая для российского рынка модель долгосрочного аутсорсинга – создание выделенного центра тестирования – изменить ситуацию? Об этом в интервью CNews рассказывает Артак Оганесян, заместитель генерального директора по развитию бизнеса компании EPAM Systems.

CNews: Насколько востребована сегодня передача тестирования программного обеспечения на аутсорсинг? Ваш портрет типичного заказчика этой услуги?

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

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

CNews: Частично под это описание попадают многие российские производители ПО: есть спектр программных продуктов и постоянный поток задач по их развитию, актуальны высокое качество и надежность. Эта аудитория активна как заказчик аутсорсинга тестирования ПО?

Артак Оганесян: Отечественные софтверные компании относятся к аутсорсингу достаточно сдержанно (в отличие от своих западных коллег). Во-первых, многие считают, что лучше найти и удерживать собственный персонал, чем привлекать внешнюю команду. Чем такой подход не всегда хорош? Тем, что приходится учиться на своих ошибках, нет возможности использовать опыт других компаний. К примеру, в EPAM Systems экспертиза по тестированию (методики, технологии, практические кейсы) аккумулируется в специальном подразделении – Центре компетенции по тестированию и контролю качества ПО.

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

Во-вторых, в России длительное время процветало пиратство, и разработчики ПО оправданно опасались за сохранность своих ноу-хау. Это до сих пор влияет на отношение к аутсорсингу, хотя ведущие поставщики полностью обеспечивают защиту коммерческой тайны, начиная от готовности взять на себя юридические обязательства по сохранению конфиденциальности и заканчивая организацией для заказчиков специальных периметров безопасности. К слову, наши услуги используют Oracle, SAP и Microsoft – три гранда, напрямую конкурирующих друг с другом. За все годы сотрудничества ни один из них не высказал сомнения в способности EPAM обеспечить секретность их новейших продуктов.

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

CNews: Существуют ли ограничения на передачу тестирования на аутсорсинг? Какие виды тестирования можно отдать внешнему партнеру, а какие нет?

Артак Оганесян: Можно отдать все. Хотя, конечно, ограничения есть. Надо смотреть по ситуации. Сложнее всего иметь дело с масштабным нагрузочным тестированием и проведением стресс-тестов. Часто в этом случае требуется собрать тестовый стенд, максимально приближенный к реальным условиям эксплуатации системы, поскольку имитация работы на меньшей модели среды не принесет нужных результатов. Построение тестовой инфрастуктуры, которая по масштабам соответствует промышленной, связано с серьезными финансовыми и трудовыми затратами. Представьте себе систему сотового оператора, где в день обрабатываются сотни миллионов записей по трафику десятков миллионов абонентов, или комплекс систем для розничного банка, обслуживающего миллионы транзакций нескольких тысяч отделений и десятков тысяч терминалов. Работа подобных "махин" обеспечивается с помощью мощного дата-центра, на создание которого понадобились бы солидные средства. Добавьте к этому построение резервного центра. И когда речь заходит об аналогичных по объему инвестициях на создание тестового окружения, финансовые директора и собственники бизнеса грустнеют и не понимают, зачем это надо делать для стороннего подрядчика. Ряд наших заказчиков предоставляют для тестирования свои мощности. Альтернативой может быть использование виртуальных сред и партнерских тестовых стендов, в частности, IBM и HP дают доступ в свои лаборатории. Тем не менее препятствие в виде невозможности создания полной копии промышленной среды в рамках тестового стенда существует, и в некоторых проектах обойти его трудно.

CNews: На основе каких моделей аутсорсинга наиболее эффективно выстроить сотрудничество заказчика и подрядчика: фиксированная стоимость, фактические трудозатраты, выделенный центр?

Артак Оганесян: Все зависит от конкретной ситуации. Разовые проекты часто реализуются по модели "фактические трудозатраты" (time and material – T&M). Но когда есть четко согласованные объемы тестирования (например, прогон такого-то количества тестов в такие-то сроки), то можно использовать модель "фиксированной стоимости" (fixed cost – FC).

Но нередко заказчик говорит: "Раз в квартал у нас выходит новая версия системы, ежемесячно – небольшая "заплатка". Давайте вы будете раз в месяц собираться маленькой командой для тестирования обновлений, а ежеквартально – большой командой для испытаний новой версии". Для таких проектов модели fixed cost или time and material – не лучший выбор. Во время паузы между выходом версий или патчей подрядчик перебросит команду на другой проект – и она не успеет освободиться к новому этапу тестирования для данной компании. В результате заказчик не получит именно тех ребят, которые выполняли проверку предыдущих версий его системы и которые уже прекрасно разбираются в ее специфике и особенностях использования.

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

CNews: Выделенная команда располагается на территории заказчика или поставщика услуги?

Артак Оганесян: Возможны различные варианты. Большинство заказчиков в нашей стране сосредоточили свои головные офисы в столицах – Москве и Санкт-Петербурге, где очень высокие зарплаты ИТ-специалистов, большие затраты на аренду помещений, выстраивание инфраструктуры и т.д. Так что держать команду тестировщиков в центральном офисе заказчика или аутсорсера невыгодно. С точки зрения оптимизации стоимости лучше построить выделенный центр тестирования в регионе. Здесь прямые и накладные расходы меньше столичных. При том же уровне квалификации и опыта сотрудники получают зарплаты на 20-30% ниже московских, они более лояльны к работодателю и менее подвержены соблазну быстро менять одну компанию на другую.

В нашей практике есть примеры, когда наши центры тестирования встраивались в инфраструктуру регионального отделения заказчика. Один из них - центр тестирования для Citi в России и СНГ, построенный на базе офиса этого банка в Рязани. Сейчас в нем работают порядка 40-50 человек, которые постоянно заняты на проведении функционального, нагрузочного, интеграционного тестирования систем банка, а также привлекаются для проведения приемочного тестирования ИТ-решений, разработанных для заказчика другими ИТ-компаниями.

Однако часто услуги по тестированию оказываются нами удаленно. В этом случае мы находим юридические, организационные и процессные условия, которые подходят и нам, и заказчику. Тогда сотрудничество является безопасным и взаимовыгодным, а, значит, успешным.

Встречается и смешанный вариант: часть команды находится в головном центре клиента, часть – в региональном офисе EPAM.

CNews: С какими рисками с точки зрения заказчика связан аутсорсинг тестирования ПО?

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

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

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

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

Для защиты данных в случае расположения центра на территории аутсорсера выстраивается специальный контур безопасности. Это спектр организационных, технических, кадровых, юридических мер, которые позволяют полностью избежать случаев утечки информации. Дополнительная гарантия появляется, если производственные процессы аутсорсера сертифицированы по стандартам информационной безопасности, например, SAS70 Type II или ISO/IEC 27001:2005.

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

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

CNews: Как распределяются функции между ИТ-службой заказчика и выделенным центром тестирования?

Артак Оганесян: Многое зависит от того, с каким "наследством" заказчик пришел к моменту принятия решения об аутсорсинге. Если в штате компании есть сильные руководители и специалисты по тестированию и контролю качества, то подготовку стратегии, плана и сценариев тестирования они могут взять на себя, оставляя рутинные операции подрядчику.

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

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

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

CNews: Наверняка у вас есть свои собственные процессы, методики и инструменты тестирования, а у заказчика могут быть свои предпочтения. Вы рекомендуете свой подход или подстраиваетесь под имеющийся у него?

Артак Оганесян: Возможны оба подхода. EPAM часто предлагает свои варианты методик и инструментов тестирования: мы подбираем их исходя из своего опыта и требований заказчика, задач тестирования, особенностей конкретного решения и инфраструктуры. К примеру, для автоматизации нагрузочного тестирования могут использоваться как коммерческие решения, так и open source-продукты. Критерий для выбора здесь - насколько хорошо то или иное средство решает поставленные задачи. Коммерческие решения более удобны в работе, у них лучше производительность. Кроме того, производители таких решений обычно обеспечивают хорошую поддержку пользователей. Бесплатные инструменты могут уступать коммерческим в универсальности и удобстве применения, но на некоторых проектах их возможностей вполне хватает для решения поставленных задач в полном объеме. Выбор конкретной системы проводится на основе анализа задач заказчика: из представленных на рынке подбирается именно тот инструмент, который поможет решить их максимально эффективно.

Иногда инициатива исходит от заказчика, например, если им уже куплены стандартные пакеты от HP, IBM или других поставщиков, то мы должны применять их. Если у ИТ-департамента сформировались строго определенные методики тестирования, то разумнее под них адаптировать наши процессы.

CNews: Каким образом можно оценить качество работы выделенного центра тестирования?

Артак Оганесян: Как правило, это происходит за счет использования системы метрик. Для этого необходимо фиксировать все выполненные операции, количество выявленных и устранённых дефектов, открытых и решенных инцидентов, другую статистику в разрезе отдельных этапов тестирования – внутреннее тестирование самими разработчиками и группой тестирования, приемо-сдаточные испытания, пользовательское тестирование, опытная или промышленная эксплуатация. Данные заносятся в информационную систему для управления проектами (в EPAM, например, для этих целей используется собственная разработка – система EPAM Project Management Center) и затем анализируются. Идеальный случай – это уменьшение количества ошибок с каждой стадией тестирования и доведение его до нуля к финальному этапу запуска в эксплуатацию. Это означает, что на всех этапах была сделана качественная работа. Если же мы видим, что на этапе внутреннего тестирования дефектов немного, во время приемо-сдаточного тестирования их нет, а у пользователей вдруг обнаруживаются ошибки, то, значит, пора принимать меры и досконально разбираться, почему так происходит. Возможно, формально подошли к приемке, а проектная команда мало внимания уделила тестированию. Иногда объективно нельзя предвидеть все ошибки, с которыми можно столкнуться в процессе ежедневного применения системы, – тесты не могут воспроизвести все ситуации, которые возникают в реальной жизни. Тогда выявленная ошибка заносится в тесты, и в следующий раз этот дефект не будет пропущен. Худший случай, когда ошибку можно было проверить заранее, однако это не было сделано.

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

CNews: Насколько использование системы метрик позволяет оценивать стоимость тестирования?

Артак Оганесян: В полной мере. Для этого нужно отслеживать трудозатраты и соотносить их со ставками специалистов. Это позволит не только оценить стоимость проведения каждого этапа и вида тестирования, но и даст возможность понять, как ее можно оптимизировать. Например, можно набрать сотню рядовых тестировщиков и вручную протестировать все возможные комбинации использования системы, например, матрицу серверных и клиентских платформ, версий операционных систем и браузеров и т.д. Другой вариант – сформировать команду из десятка экспертов в автотестах, чья квалификация (но и стоимость) будут выше: они настроят среду тестирования, подберут или напишут автоматические тесты и оптимально выстроят сам процесс тестирования. Тогда в дальнейшем нам уже потребуется не 100 человек, а всего 10-20 специалистов, которые проверят только тот функционал, тестирование которого сложно или пока невозможно автоматизировать. Это позволит в дальнейшем (например, при выпуске новой версии системы) снижать стоимость тестирования.

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

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

Оригинал публикации