Когда подключать SDET-специалиста на проект и как на этом сэкономить

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

На практике SDET-специалист совмещает компетенции разработчика, автоматизатора тестирования, QA и DevOps-инженера. Он знает языки программирования, необходимые ему в работе фреймворки, теорию тестирования, алгоритмы и паттерны проектирования.

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

Почему трудно найти универсального специалиста?

Потенциальные заказчики часто приходят к нам за универсальным специалистом, в котором должны сочетаться компетенции в области ручного и автоматизированного тестирования, нагрузочного тестирования, а иногда еще и проектного менеджмента. Согласитесь, трудно представить, как сочетание всех этих компетенций может уложиться в 8 часов рабочего времени при максимальной отдаче в каждом направлении. 

Усилия fullstack-специалиста по тестированию (далее — QA Fullstack) будут вынужденно балансировать между полностью ручным тестированием и разработкой средств автоматизации. Баланс крайне сложный в реальности: перекос может быть то в одну, то в другую сторону. В срочных предрелизных задачах приоритет всегда будет отдан в сторону ручного тестирования, а средства автоматизации в таком случае уже используются не на максимуме эффективности.

Получив подобные запросы, мы стараемся выяснить у клиента:

• приоритетные задачи команды и на чем должны быть сфокусированы силы специалиста
• какой результат по качеству и продуктивности от работы такого специалиста он ожидает

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

Почему в реальности трудно нанять универсального специалиста, который умеет все? Чтобы в этом разобраться, предлагаю рассмотреть последовательность задач с позиции релизного цикла. 

Итак, команда нанимает на проект единственного QA Fullstack.

Этап 1. Допустим, команда выпускает релизы раз в 2 недели. Пока разработчики заняты созданием новой функциональности, примерно 4 дня QA Fullstack будет сосредоточен на составлении тестовой документации: тест-плана и тест-кейсов. Сегодня все понимают, что без них сложное приложение существовать не сможет.

Этап 2. Когда разработчики заканчивают работу над фичами, наступает время тестирования. QA Fullstack проводит его вручную, потому что автотесты к этому времени он, скорее всего, физически не успеет подготовить. Если выявили неточности, фича отправляется на доработку с последующим ручным тестированием для проверки изменений.

Этап 3. Представим, что второй этап прошел идеально и команда готовится к релизу. В разгаре уже вторая неделя. Перед релизом необходимо провести регресс — проверку ранее протестированного ПО или его отдельных компонентов, которая позволяет удостовериться, что последние внесенные изменения не привели к появлению дефектов в неизмененной части программы. Здесь QA Fullstack может воспользоваться автотестами, если они есть к этому моменту. Далее автотесты можно немного доработать или актуализировать, чтобы они стали частью регресса на конкретный релиз.

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

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

Возвращаемся в начало истории. Попытка сэкономить за счет подключения «универсального солдата» — это  правильный шаг, особенно в условиях кризиса, но важно при этом учитывать и другие аспекты работы, которые не описываются экономикой. QA Fullstack — специалист, который имеет опыт в ручном тестировании и зачастую идет на проекты с целью развития в области автоматизации. Но никто вам не скажет, как долго специалист сможет работать в таком режиме и к какому результату это приведет. В вышеописанном примере это может привести к демотивации сотрудника, не самым лучшим результатам работы и, как следствие, уходу с проекта. Не говоря уже о специалистах, которые, помимо автотестов, согласно требованиям заказчика должны посвящать себя нагрузочному тестированию и управлять командой.

Что делать? Подобрать конкретного специалиста, будь то QA Fullstack, просто QA или SDET не составит особого труда, главное, чтобы сотрудник мог достигнуть конкретных целей. 

На мой взгляд, единственное решение — переговоры с корректировкой ожиданий и уточнениями, начиная с того, кто требуется и какие цели стоят перед командой, заканчивая тем, как устроен тот или иной процесс в команде. Так вы сможете получить наиболее релевантного специалиста, который поможет решить ваши проблемы и задачи.

Когда SDET-специалист не нужен, а на каких проектах без него не обойтись?

Есть несколько критериев, по которым следует определять, поможет экспертиза SDET вашему проекту или нет. 

Подключение SDET-специалиста, скорее всего, не принесет ожидаемого результата, если:

• Планируется MVP
• Длительность проекта не больше полугода
• Есть небольшая функциональность на 200-300 тест-кейсов
• Требуется менять устаревшую функциональность
• После сдачи продукта не планируется поддержка 

Но подключение SDET точно окупится, если:

• Длительность проекта — от 10 месяцев и более
• Есть большой набор функций, большой объем данных, алгоритмы, расчеты и множество интеграций
• Выполняются частые релизы — раз в 2 дня
• На проекте работает большая команда — от 10 человек и более
• Есть поддержка пользователей

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

— Как сэкономить, привлекая SDET-специалиста?

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

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

Вы можете сказать, что примерно столько же дней потратит и QA. Но если посчитать, то при той же частоте релизов 24 раза в год запускать автотесты можно сколько угодно раз. Между тем, ближе к релизу запуск автотестов проходит 3 раза в течение спринта. Если бы QA проводил регресс по 3 раза каждый релиз, то за год получили бы 72 прогона тестов. Умножив это число на время работы и ставку, можно получить объем затрат на проведение этого этапа тестирования. 

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

Таким образом, вы оплатите только время на разработку автотестов один раз и около одного часа на разбор отчетов после каждого пройденного запуска, чтобы выдать результат о состоянии продукта, его качестве и готовности к релизу. Конечно, в реальной ситуации расчеты более сложные. Но в перспективе вы все равно получаете экономию средств, времени и сил команды на поддержание темпа релизов.  

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

Как ускорить онбординг привлеченного SDET-специалиста?

Если специалисты подключаются в режиме аутстаффинга, то на плечи команды заказчика ложится решение нескольких вопросов:

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

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

На самом деле вопросов, нюансов, а иногда и сложностей бывает гораздо больше. Подробнее о возможностях и компетенциях SDET рассказывали на сайте. 

Для вашего удобства прикрепляем и видеоверсию интервью