Поделиться
Артак Оганесян: Тестировщику полезно услышать крики пользователей
Передачей процессов разработки ПО на аутсорсинг сегодня сложно кого-то удивить. Эту практику активно применяют организации самых разных направлений деятельности. Напротив, тестирование программного обеспечения компании до последнего стараются выполнять своими силами, не доверяя внешним командам проверку качества и надежности информационных систем. Что мешает организациям более широко использовать аутсорсинг в этой сфере? Как эффективно выстроить взаимодействие с подрядчиком и оценить качество его работы? Способна ли новая для российского рынка модель долгосрочного аутсорсинга – создание выделенного центра тестирования – изменить ситуацию? Об этом в интервью CNews рассказывает Артак Оганесян, заместитель генерального директора по развитию бизнеса компании EPAM Systems.Помимо этого аутсорсер предоставляет гарантии, что команда центра не будет участвовать в проектах для конкурентов заказчика, иногда даже в течение определенного периода после участия в проектах или окончания сотрудничества (1-3 года). Кроме того, важно защитить конфиденциальность информации, связанной с алгоритмами и логикой тестируемых систем. Например, если специалист испытывает скоринговую систему банка, то он знает, как она работает и как потенциально ее можно обойти. Такие вещи решаются за счет подписания со специалистами центра юридических соглашений о неразглашении информации и неприменении знаний в ущерб заказчику.
CNews: Как распределяются функции между ИТ-службой заказчика и выделенным центром тестирования?
Артак Оганесян: Многое зависит от того, с каким "наследством" заказчик пришел к моменту принятия решения об аутсорсинге. Если в штате компании есть сильные руководители и специалисты по тестированию и контролю качества, то подготовку стратегии, плана и сценариев тестирования они могут взять на себя, оставляя рутинные операции подрядчику.
Артак Оганесян: EPAM часто предлагает свои варианты методик и инструментов тестирования: мы подбираем их исходя из своего опыта и требований заказчика, задач тестирования, особенностей конкретного решения и инфраструктуры
Если аутсорсер привносит свою экспертизу (например, у заказчика нет опыта в автоматизированном функциональном тестировании или выстраивании процессов разработки и тестирования по методологии continuous integration – непрерывная интеграция), то тогда основная инициатива по подготовке тестирования и распределению работ исходит от него. Может быть такой вариант, что внешних специалистов сначала привлекают для решения отдельных задач и расширения команды, но затем постепенно передают им все больше и больше управленческих и производственных функций.
Для коммуникаций между заказчиком и внешней командой используются все возможности – от проведения видеоконференций, применения скайпа и других средств общения до регулярных очных встреч и командировок.
Хочу обратить внимание на еще один момент. Нужно провести четкую границу между группами тестирования и разработки, поскольку их интересы могут и даже должны противоречить друг другу. Для разработчика важно как можно быстрее создать функциональность решения и сдать его. Тестировщику необходимо тщательно все проверить, удостовериться, что нет дефектов, проблем или несоответствия начальным требованиям. Когда сроки поджимают, то руководитель проекта нередко начинает давить на группу тестирования. Иногда и сами тестировщики начинают "болеть" за общий результат и более терпимо относиться к недостаткам разрабатываемой системы. Все это чревато проблемами с качеством конечного продукта. Так что важно правильно разграничить полномочия, наделить тестировщиков правом вето на приемку результатов работ или, по крайней мере, правом прямой связи с руководством выше, чтобы донести информацию о возможных рисках. Это поможет эффективно распределить баланс в соотношении "сроки – бюджет – качество" проекта.
CNews: Наверняка у вас есть свои собственные процессы, методики и инструменты тестирования, а у заказчика могут быть свои предпочтения. Вы рекомендуете свой подход или подстраиваетесь под имеющийся у него?
Артак Оганесян: Возможны оба подхода. EPAM часто предлагает свои варианты методик и инструментов тестирования: мы подбираем их исходя из своего опыта и требований заказчика, задач тестирования, особенностей конкретного решения и инфраструктуры. К примеру, для автоматизации нагрузочного тестирования могут использоваться как коммерческие решения, так и open source-продукты. Критерий для выбора здесь - насколько хорошо то или иное средство решает поставленные задачи. Коммерческие решения более удобны в работе, у них лучше производительность. Кроме того, производители таких решений обычно обеспечивают хорошую поддержку пользователей. Бесплатные инструменты могут уступать коммерческим в универсальности и удобстве применения, но на некоторых проектах их возможностей вполне хватает для решения поставленных задач в полном объеме. Выбор конкретной системы проводится на основе анализа задач заказчика: из представленных на рынке подбирается именно тот инструмент, который поможет решить их максимально эффективно.
Иногда инициатива исходит от заказчика, например, если им уже куплены стандартные пакеты от HP, IBM или других поставщиков, то мы должны применять их. Если у ИТ-департамента сформировались строго определенные методики тестирования, то разумнее под них адаптировать наши процессы.
CNews: Каким образом можно оценить качество работы выделенного центра тестирования?
Артак Оганесян: Как правило, это происходит за счет использования системы метрик. Для этого необходимо фиксировать все выполненные операции, количество выявленных и устранённых дефектов, открытых и решенных инцидентов, другую статистику в разрезе отдельных этапов тестирования – внутреннее тестирование самими разработчиками и группой тестирования, приемо-сдаточные испытания, пользовательское тестирование, опытная или промышленная эксплуатация. Данные заносятся в информационную систему для управления проектами (в EPAM, например, для этих целей используется собственная разработка – система EPAM Project Management Center) и затем анализируются. Идеальный случай – это уменьшение количества ошибок с каждой стадией тестирования и доведение его до нуля к финальному этапу запуска в эксплуатацию. Это означает, что на всех этапах была сделана качественная работа. Если же мы видим, что на этапе внутреннего тестирования дефектов немного, во время приемо-сдаточного тестирования их нет, а у пользователей вдруг обнаруживаются ошибки, то, значит, пора принимать меры и досконально разбираться, почему так происходит. Возможно, формально подошли к приемке, а проектная команда мало внимания уделила тестированию. Иногда объективно нельзя предвидеть все ошибки, с которыми можно столкнуться в процессе ежедневного применения системы, – тесты не могут воспроизвести все ситуации, которые возникают в реальной жизни. Тогда выявленная ошибка заносится в тесты, и в следующий раз этот дефект не будет пропущен. Худший случай, когда ошибку можно было проверить заранее, однако это не было сделано.
Оценка качества тестирования по метрикам, связанным с количеством несоответствий и логических ошибок, не всегда срабатывает в случае, если разрабатывается система для поддержки совершенно нового направления бизнеса. Заказчик не до конца знает, что конкретно ему необходимо, соответственно, нельзя четко сформулировать все требования к ИТ-решению. Нужно быть готовым к тому, что ошибки всплывут на финальных этапах тестирования и это будет показателем непроработанности на этапах аналитики или проектирования, а не плохой работы тестировщиков.
CNews: Насколько использование системы метрик позволяет оценивать стоимость тестирования?
Артак Оганесян: В полной мере. Для этого нужно отслеживать трудозатраты и соотносить их со ставками специалистов. Это позволит не только оценить стоимость проведения каждого этапа и вида тестирования, но и даст возможность понять, как ее можно оптимизировать. Например, можно набрать сотню рядовых тестировщиков и вручную протестировать все возможные комбинации использования системы, например, матрицу серверных и клиентских платформ, версий операционных систем и браузеров и т.д. Другой вариант – сформировать команду из десятка экспертов в автотестах, чья квалификация (но и стоимость) будут выше: они настроят среду тестирования, подберут или напишут автоматические тесты и оптимально выстроят сам процесс тестирования. Тогда в дальнейшем нам уже потребуется не 100 человек, а всего 10-20 специалистов, которые проверят только тот функционал, тестирование которого сложно или пока невозможно автоматизировать. Это позволит в дальнейшем (например, при выпуске новой версии системы) снижать стоимость тестирования.
С точки зрения стоимости тестирования есть и другой "подводный камень". Многие заказчики настаивают на привязке метрик качества работ к штрафам. Если обнаружены проблемы в ходе приемочного тестирования пользователями, то оплата услуг подрядчика производится не в полном объеме. Если что-то выявляется при запуске в промышленную эксплуатацию, то команда тестирования штрафуется на некоторую сумму в зависимости от критичности инцидента. В целом такой подход может быть оправдан, но тут важно избежать перекосов. Напуганный возможным объемом санкций, на каком-то этапе подрядчик начнет перестраховываться и стараться закрыть тестами все и вся. И в результате стоимость тестирования вырастет в разы. Выпуск новой версии затянется на срок, который не устроит бизнес. Так что надо взвешивать все факторы, возможно, мотивировать подрядчика именно на соблюдение сроков, даже если велика вероятность, что в системе остались незначительные ошибки. Они не настолько критичные и их устранение уже в ходе эксплуатации для заказчика обойдется гораздо дешевле.
В этом смысле организация выделенного центра эффективна тем, что дает возможность мониторить качество и стоимость тестирования на протяжении длительного времени. Это помогает в конечном итоге прийти к тому уровню услуг, который устроит и заказчика, и подрядчика. Постоянный характер сотрудничества позволяет накапливать экспертизу, не начинать с нуля каждый проект и выстроить четкие и прозрачные процессы тестирования ИТ-решений. Какая еще модель аутсорсинга способна обеспечить такие преимущества?
Короткая ссылка
