Когда подключать SDET-специалиста на проект и как на этом сэкономить
Тестирование — важнейший элемент обеспечения качества ИТ‑продукта. В условиях высокой конкуренции и динамичных рыночных процессов бизнес стремится ускорить выпуск продуктовых релизов. В ответ на этот запрос растет востребованность специалистов SDET (Software Development Engineer in Test) — инженеров, которые занимаются разработкой инструментов для автоматизированного тестирования ПО.
SDET-специалист совмещает компетенции разработчика, автоматизатора тестирования, QA и DevOps-инженера. Он знает языки программирования, необходимые ему в работе фреймворки, теорию тестирования, алгоритмы и паттерны проектирования.
В этом материале расскажем о разработке автотестов и том, насколько это выгодно с точки зрения временных и финансовых затрат.
Роль универсального SDET-специалиста в проекте
Потенциальные клиенты ищут универсального специалиста, обладающего компетенциями в ручном и автоматизированном тестировании, нагрузочном тестировании и даже в проектном менеджменте. Однако совместить все эти навыки и эффективно применять их в рамках стандартного 8‑часового рабочего дня — задача со звездочкой.
Поддерживать равновесие непросто, но получив подобный запрос, мы определяем два критерия: ключевой приоритет (на чем именно должен сосредоточиться специалист) и какой качественный результат заказчик ожидает получить.
Существуют ли специалисты, которые умеют все?
Рассмотрим на примере одного из наших проектов
Заказчик нанимает единственного QA Fullstack.
Этап 1
Релизы раз в 2 недели. Пока разработчики продумывают функционал продукта, QA Fullstack составляет тестовую документацию: тест-планы и тест-кейсы — без них сложное приложение работать не будет
Этап 2
После работы над фичами наступает время тестирования. QA Fullstack проводит его вручную и, если обнаруживает неточность, отправляет фичу на доработку с последующим ручным тестированием.
Этап 3
Второй этап пройден, готовим релиз. Проводим регресс: проверяем, не сломалось ли что‑то после изменений. Используем и дорабатываем автотесты под релиз (если они есть к этому моменту).
Этап 4
После релиза мониторим системы и жалобы пользователей. При обнаружении багов принимаем решение о хот‑фиксе, проводим ретест и, если нужно, дополнительные проверки. Написание новых автотестов откладывается: в приоритете — срочные задачи.
Возвращаясь к началу: экономия на «универсальном солдате» (например, QA Fullstack) оправдана в кризис, но чревата рисками. Такой специалист, имея опыт ручного тестирования и стремясь развиваться в автоматизации, может:
-
демотивироваться из‑за перегрузки;
-
показывать нестабильные результаты;
-
уйти с проекта.
Что делать? Не искать «универсала», а четко определять потребности — нужен ли QA, QA Fullstack или SDET.
Ключевое — переговоры:
-
уточнить требуемую роль и цели;
-
прояснить процессы в команде.
Подключение SDET-специалиста к проекту, скорее всего, не принесет ожидаемого результата, если:
-
планируется MVP
-
длительность менее полугода
-
есть небольшая функциональность на 200-300 тест-кейсов
-
требуется менять устаревшую функциональность
-
после сдачи продукта не планируется поддержка
Но подключение SDET точно окупится, если:
-
длительность проекта — от 10 месяцев и более
-
есть большой набор функций и данных, алгоритмы, расчеты и множество интеграций
-
ожидаются частые релизы — раз в 2 дня
-
на проекте работает большая команда — от 10 человек и более
-
есть поддержка пользователей
В целом, если проект долгосрочный, автоматизация тестирования принесет пользу за счет сокращения времени прогона регресса.
Привлечь SDET-специалиста и сэкономить
При стандартном двухнедельном спринте в году выйдет примерно 24 релиза. Получается QA‑специалист тратит по 2–3 дня на регресс‑тестирование перед каждым релизом (итого 48–72 рабочих дня). При 24 релизах в год порой одного прогона недостаточно.
Решение: подключить SDET для разработки автотестов. На создание уйдет 1–2 месяца.
При использовании автотестов для проведения регресса каждый запуск обойдется бизнесу в 0 рублей, т.к. разработка уже оплачена. Плюсы: автотесты можно запускать многократно (например, 3 раза за спринт) и есть опция автоматического запуска, даже ночью.
Экономия простая: оплачивается только время на разработку автотестов (один раз) и около одного часа времени на разбор отчетов после каждого пройденного запуска.
Ускоряем онбординг SDET-специалиста
При аутстаффинге команда заказчика должна заранее определить задачи и сроки их выполнения, сформулировать критерии приемки работ и подготовить все необходимые доступы в системы (чтобы в первый день лишь проверить их).
При аутсорсинге эти задачи берет на себя подрядчик: он управляет командой, решает вопросы с доступами, контролирует сроки и качество работ.
