Почему тестирование ПО стоит отдать на аутсорс, тем более — сейчас

Лев Шелковой: Все началось несколько лет назад, когда пандемия ускорила цифровую трансформацию множества отраслей. IT-рынок стал перегреваться — ресурсы требовались для разработки решений практических во весь сферах. Создаваемые приложения, ПО или сервисы — все это требует аналитики, разработки и тестирования. На последнем хотелось бы сделать особый акцент, ведь современные пользователи крайне требовательны и дают новому сервису только один шанс.

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

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

Лев Шелковой: Есть две схемы работы с тестированием коммерческого ПО. Формат time&material предусматривает, что специалисты взаимодействуют с заказчиком определенное количество часов, и он ими управляет. Другой вариант — fix price — конкретное ТЗ, бизнес-требования, которые мы анализируем, уточняем все детали. Это сервисная модель под ключ, для которой мы формируем команду — руководитель проектов, лиды, специалисты разных уровней. То есть комплексный пакет тестирования ПО: мы договариваемся о каких-то вехах и промежуточных результатах, всегда есть заключение по найденным ошибкам, их критичности, перечень того, что нужно исправлять и как. Если говорить о perfomance-тесте, здесь мы проводим тесты на стабильность, прогоняем множество сценариев — как ведет себя ПО в различных состояниях. И даем заключение о пропускной способности, максимуме, который выдерживает это ПО на текущих мощностях, а также рекомендации — если вдруг выявлена какая-то деградация, где и что необходимо поправить, чтобы выровнять производительность решения. Продолжительность такой работы зависит от функциональности продукта и количества систем, которые могут быть затронуты во время тестирования. Один софт можно протестировать за неделю, а для другого необходимо несколько месяцев работы — поскольку речь идет о масштабной интеграции.

Лев Шелковой: Если вендор работает по методологии agile со спринтами раз в две недели, наши тестировщики подключаются регулярно. Они идут сверху вниз, с описания матриц, покрытий, дерева требований, возможных тестовых сценариев. Мы с самого начала должны понимать, сколько будет тестовых сред — бывает, тесты прогоняются на одной среде, бывает — на трех, могут быть повторные циклы тестирования, чтобы гарантировать качество, нужное заказчику. В некоторых случаях клиенты говорят, что минорные, тривиальные дефекты, не влияющие на функциональность, им не принципиальны (и их поправят потом). Обычно это происходит в гонке за time to market — чтобы снять сливки с рынка, показать MVP и довести продукт до конечных пользователей.

iFellow часто становится постоянным партнером для разработчиков коммерческого ПО — если есть потребность в развитии продукта, то необходимо и его регулярное тестирование. Любые вносимые изменения могут вызвать отклонения в уже действующем функционале. Поэтому есть и регрессионное тестирование — специалисты проверяют и новую функциональность, и покрывают прежнюю, удостоверяясь, что она не затронута новшествами.TAdviser выпустил новую Карту «Цифровизация ритейла»: 280 разработчиков и поставщиков услуг 14.2 т

И мы гарантируем заказчикам стабильную команду на проекте — не перекидываем специалистов с одного проекта на другой, а обеспечиваем накопление экспертизы в команде. Единственное исключение — профессиональный рост нашего сотрудника. Например, над проектом работает 10 функциональных тестировщиков, один из них прошел подготовку (в iFellow мы обучаем и прокачиваем скиллы сотрудников) и теперь будет проводить preformance-тесты. В этом случае мы обязательно предупреждаем заказчика как минимум за месяц, что один из специалистов будет заменен на аналогичного по уровню компетенций сотрудника.

Лев Шелковой: Такая внешняя услуга решает несколько задач. Сможет ли сам разработчик привлечь подобных специалистов? На практике это часто становится камнем преткновения. Внутри такой компании нужны грамотные управленцы: если функциональность продукта серьезная, команд будет много — нужно уметь оркестрировать. Смоделируем ситуацию: есть вендор, который активно участвует в программе импортозамещения. У его продукта определенный уровень функциональности, который еще предстоит развивать. У компании есть несколько клиентов, но случились февральские события, ее выбрали сразу несколько крупных организаций — и каждая начала говорить, что «вот этот backlog нужно срочно разработать». Но как это сделать? Выйдя на рынок, вендор будет долго отбирать и нанимать людей, а специалисты на задачу нужны уже сейчас, причем в интенсивном режиме. Вариант — обращаться в IT-компании с тренированными «бойцами». Наши команды географически распределены по территории страны — благодаря этому временной диапазон разработки, сопровождения или техподдержки наших специалистов увеличен с 8 часов до 10-12 рабочих часов.

Второй момент: на пике компании нужно 50 разработчиков, спустя полгода-год — всего 10 для сопровождения продукта. Что же, компания сначала наберет людей, а потом уволит? Это репутационные риски и головная боль, кроме того, говорить про компетенции и экспертизу тогда не приходится. Десятилетия опыта на западных рынках показывают, что финансово выгоднее привлекать для таких задач интеграторов. Ведь внешних факторов, которые могут произойти в мире или на территории одного государства – множество.