Объемы рынка ИТ-аутсорсинга постоянно растут. Все больше мировых и российских компаний предпочитают отдавать часть функций на аутсорсинг, в том числе, тестирование программного обеспечения.
И это объяснимо: при использовании аутсорсинга нет налогов, связанных с зарплатой, нет больничных и отпусков, нет необходимости тратить время на поиск и погружение в рабочий процесс сотрудника, на оборудование его рабочего места. А все спорные моменты решаются внесением поправок в договор.
Согласно исследованию консалтинговой компании Capgemini, передача работ по тестированию программного обеспечения позволяет сократить расходы на 25%. Наиболее же оптимистично настроенные руководители говорят о 45%.
В то же время, многие компании все еще с опаской относятся к передаче работ по тестированию команде, которая находится в другом городе или даже в другой стране. Особенно, если речь идет о разработке ПО по гибким методологиям, что предусматривает постоянные изменения в требованиях к продукту. Есть ли основания для таких опасений? Давайте разберемся.
Что стоит учесть при найме аутсорс-команды по тестированию по?
Большинство беспокойств связаны с разницей во времени, культурными особенностями и налаживанием коммуникации команды с сотрудниками компании, а также способностью внешней команды быстро подстраиваться к меняющимся условиям на проекте. И если первые три беспокойства легко решаются на этапе обсуждения, то с изменениями так просто не разобраться.
Изменения в требованиях могут привести к росту затрат на тестирование
Это опасение обосновано. Во-первых, изменения в требованиях предполагают адаптацию плана тестирования и изменение тест-кейсов. А это дополнительные затраты времени и бюджета.
Во-вторых, даже незначительные дополнения в функциональности требуют проведения большого объема регрессионного тестирования. И тут существует риск того, что тестировщиками будет создан огромный набор тест-кейсов, которые неясным образом будут связаны с задачами, функциональностью, а также между собой.
Решение
Указанные сложности можно преодолеть, наняв
компетентную QA-команду по тестированию с опытом работы по гибким методологиям, что поможет снизить стоимость внедрения изменений.
На Agile-проекте команда тестировщиков начинает работу на стадии анализа требований к продукту. Это действительно важно, поскольку стоимость исправления дефектов ПО на этапе требований невелика, тогда как устранение этого же дефекта после выпуска продукта на рынок может стоить в тысячи раз больше.
Большие объемы регрессионного тестирования – также не проблема для профессиональных QA-инженеров, которые управляют тестированием на основе рисков (Risk-Based Testing). Этот подход позволяет определить те зоны программного решения, которые вероятнее всего будут затронуты при внедрении новой функциональности, и, в первую очередь, проверить именно их. Такой подход позволяет сократить объемы тестирования за счет расстановки четких приоритетов.
А как быть с созависимостью тест-кейсов?
Опытная команда тестировщиков использует лучшие практики и специальные инструменты для организации удобной работы с тест-кейсами. Упорядочить работу позволяет создание тестовой модели, в которой тест-кейсы перелинкованы с требованиями заказчика и пользовательскими историями. При масштабировании команды данный подход помогает новичкам быстрее сориентироваться во всем объеме тест-кейсов.
Синхронизация разработки и тестирования
Сократить релизный цикл и ускорить процесс вывода продукта на рынок поможет синхронизация работы разработчиков и тестировщиков. Но если ваша команда по тестированию находится где-то далеко и живет по другим часовым поясам, задача может казаться невыполнимой.
Эта трудность, в свою очередь, сводится к тому, что в процессе регрессионного тестирования может обнаруживаться масса ошибок, вызванных изменениями в коде. Команда по тестированию начинает переписывать тест-кейсы, приводя их в соответствие с новым кодом. Время простоя команд увеличивается, момент выхода продукта на рынок отдаляется, издержки на разработку растут.
Решение
Обязательный компонент разработки продукта по гибким методологиям – это открытая коммуникация. Профессиональные тестировщики обновят тест-кейсы не после проведения регрессионного тестирования, а в то время, пока разработчики будут вносить изменения в код. Если QA- и Dev-команды работают синхронно, набор тест-кейсов обновляется своевременно.
И при этом не имеет значения, в какой части земного шара находится ваш поставщик услуг по тестированию. Главное – ответственность и готовность адаптироваться под процесс.
Диалог имеет значение
Невозможно свести успех проекта к одной простой формуле. Изменения в требованиях вызовут дополнительные усилия как со стороны заказчика, так и со стороны поставщика услуг. Построение успешного сотрудничества в рамках Agile-проекта потребует качественной коммуникации и взятия на себя определенных обязательств.
Провайдер услуг должен оперативно реагировать на изменения в требованиях, используя отработанные техники и практики, которые, с одной стороны, позволяют подстроиться под меняющиеся требования, а, с другой стороны, не несут вреда проекту.
Кроме того, профессиональные команды тестировщиков имеют в штате и могут привлечь к проекту специалистов в индустрии, к которой принадлежит бизнес заказчика (банковское дело, телеком, ритейл и т. д.), которые, исходя из опыта работы, на ранних стадиях проекта смогут предположить, какие области продукта будут вызывать больше всего проблем. Соответственно, тестировщики смогут направить свое внимание на эти области.
Ожидая от тестировщиков эффективной и открытой коммуникации, заказчик должен понимать, что и с его стороны ожидается то же самое. Понятное и своевременное оповещение аутсорс-команды о любых идеях и четкая постановка задач сэкономят значительное время на коммуникацию и ускорят выполнение проекта.
Подведем итог
Сегодня процесс разработки ПО во многом напоминает заезды Формулы 1: сумасшедшая гонка с целью быстрее вывести продукт на рынок. И все участники процесса должны работать оперативно и слаженно, чтобы предложить стабильное и безопасное программное решение, которое будет приносить прибыль и завоевывать популярность в своей нише, а не наоборот.
Удаленная команда по тестированию может ускорить успех проекта и снизить его стоимость. Главное – помнить о том, что в основе гибкой методологии лежат принципы «Взаимодействие и люди важнее процессов и инструментов» и «Готовность к изменениям важнее следования изначальному плану». И все активности на проекте должны быть выстроены в соответствии с этими принципами.
