«Автоматизатор» или «кнопкодав»: как отличить SDET от обычного QA
За последние годы спрос на автоматизацию тестирования взлетел до небес. Кажется, любой тестировщик сегодня мечтает называться QA Automation Engineer или даже заветным словом SDET. Но означает ли это, что каждый «автоматизатор» действительно умеет писать автотесты, а не просто запускать их по шаблону? Далеко не всегда. Разберёмся, кто такой настоящий SDET, чем он отличается от «пускателя тестов» и почему бизнесу важно видеть эту разницу.
SDET: разработчик с душой тестировщика
Для начала определимся с понятиями. SDET (Software Development Engineer in Test) – это по сути программист, специализирующийся на задачах тестирования (источник habr.com). Такой инженер пишет программу для тестирования – то есть код, который сам проверяет качество другого кода. Не случайно термин SDET ввела корпорация Microsoft ещё в 2005 году, когда стало ясно, что масштабная автоматизация тестов требует новых ролей. Google называл таких специалистов SET (Software Engineer in Test), но суть та же: у SDET «сердце разработчика».
В противоположность этому, классический QA-инженер фокусируется скорее на процессах обеспечения качества, часто вручную. Его сильные стороны – знание продукта, внимательность, умение составлять сценарии и находить нестандартные дефекты. Но глубокое программирование от него исторически не требовалось. QA Automation Engineer – это, как шутят сами айтишники, «тестировщик, который выучил скриптинг и несколько инструментов автоматизации, но не обладает полным набором навыков разработчика». Проще говоря, базовый автоматизатор может записать или запустить готовый скрипт, но не всегда способен создать сложный тестовый фреймворк с нуля.
SDET же – это именно разработчик, пишущий код для тестов. Такой инженер свободно владеет языками программирования (Java, Python, C# и др.), знает фреймворки вроде Selenium/WebDriver, JUnit/TestNG, может работать с API (Postman), базами данных (SQL) и CI/CD-конвейерами. В обязанности SDET входит не только написание автотестов, но и разработка инструментов и инфраструктуры: собственных фреймворков, вспомогательных утилит, систем генерации тестовых данных, настройки параллельного прогона тестов и репортинговых дашбордов.
«Никогда не говорите SET, что он просто пишет скриптики, – предупреждает блогер-тестировщик Энди Найт. – Автоматизация тестирования включает гораздо больше: серьёзные решения требуют серьёзной разработки и усилий». По сути, автотест – такой же программный продукт, как и само приложение, и отношение к нему должно быть соответствующее.
Именно поэтому лучших SDET часто привлекают ещё на стадии проектирования. Они участвуют в обсуждении требований, смотрят код вместе с разработчиками, предлагают, что и как тестировать. Их задача – встроить качество в продукт с самого начала.
В индустрии уже шутят, что вакансий ручных тестировщиков почти не осталось: большинство позиций эволюционировали в сторону SDET. Конечно, это преувеличение – ручное тестирование нужно всегда. Но тренд очевиден: бизнесу требуются универсалы, способные и в код, и в тест-дизайн.
«Автор тестов» vs «пускатель»: в чём разница на практике
Представим двух QA-автоматизаторов. Первый – назовём его Петя – приходит на проект, где уже есть набор автотестов. Петя умеет открыть готовый тестовый проект, запустить тесты, может быть, записать простой сценарий в Selenium IDE. Он следует инструкциям и поддерживает то, что создано до него.
Такой специалист – типичный “пускатель”. В индустрии его иногда пренебрежительно называют «кнопкодав», потому что основной навык – нажимать кнопку «Run». Как отмечают опытные инженеры, нередко аутсорс-компании нанимают людей с минимальными техническими знаниями, делая ставку лишь на знание английского и усидчивость – «привет, тестировщик», даже если код писать фактически некому (источник dou.ua).
Другой же специалист – пусть будет Вася – с ходу задаётся вопросом: а покрывает ли существующий набор тестов все критичные случаи? Можно ли улучшить тестовый проект? Вася вникает в код автотестов, при необходимости рефакторит устаревшие участки, дописывает новые тест-кейсы. Более того, если автотестов на проекте не было, он способен их поставить с нуля.
Такой инженер разбирается и в ООП, и в шаблонах проектирования для тестовых сценариев, знает, когда применить Page Object или, скажем, Factory в тестовом коде (источник habr.com). Он понимает архитектуру приложения, может сам поднять, к примеру, сервис имитации (mock) или настроить тестовую базу данных. Это и есть “автор” тестов – ценный кадр, который создаёт новую ценность, а не просто выполняет заведённый ритуал.
Разница между Петей и Васей на самом деле фундаментальна. Первый – Junior Automation – без опыта и знаний, поэтому «способен лишь запускать тесты на уже готовом проекте и фреймворке, пользуясь ранее созданными блоками». Ему пока не доверяют задач по самостоятельной автоматизации – не хватит навыков программирования, знания архитектуры, да и общего кругозора в тестировании.
Второй – условно Senior – напротив, может реализовать весь проект тестирования с нуля, подобрать инструменты и спроектировать структуру автотестов под конкретный продукт. Он владеет разными подходами, знает тонкости интеграции тестов в CI/CD, умеет обучать менее опытных инженеров писать тестируемый код. Такой специалист фактически играет роль архитектора качества на проекте, а не просто исполняет тест-скрипты.
Разумеется, между этими полюсами есть градации. Средний уровень автоматизаторов способен и добавить новые тесты в уже существующий фреймворк, и немного расширить его функциональность. Но полностью построить систему с нуля без помощи разработчиков mid-level ещё не готов – это приходит с опытом. Тем не менее ключевой водораздел ясен: одни инженеры создают автотесты, другие – лишь выполняют.
Почему бизнесу не всё равно
С практической точки зрения, наличие в команде одних только «пускателей» вместо настоящих авторов тестов – серьёзный риск. Да, на первых порах любой проект может жить за счёт шаблонных решений: скажем, записанных в UI-режиме тестов или копирования чужих скриптов. Существуют даже курсы, которые обещают научить «создавать автотесты без навыков программирования» – например, используя рекордер Selenium IDE (источник skillbox.ru). Новичку легко поверить в мечту: автоматизировать тестирование, толком не зная кода.
Но реальность быстро вносит коррективы. Рано или поздно тестовый сценарий выходит за рамки возможностей рекордера – и некому написать нужный скрипт. Автотесты начинают падать при малейшем изменении продукта – и некому их починить, кроме разработчиков, у которых и так полно задач. В итоге вместо ускорения мы получаем замедление процесса: тесты есть, но доверия к ним нет.
Напротив, грамотный SDET-инженер с самого начала закладывает в автотесты гибкость и надёжность. Такой специалист автоматизирует то, что действительно нужно, и выбирает инструменты с учётом перспективы. Например, опытный автоматизатор знает, что не все проверки стоит переводить в автотесты: какие-то быстрее сделать вручную или с помощью простого скрипта, чем тратить недели на поддержку избыточного UI-теста.
Он понимает «пирамиду тестирования» (больше быстрых модульных тестов, меньше – дорогих end-to-end) и сможет обосновать эту стратегию бизнесу. В диалоге с менеджментом SDET говорит на языке ценности: объясняет, какие риски покрывают тесты и сколько времени экономят на релизе. Такой инженер не боится, что себя заменит автотест – наоборот, он сам себя частично автоматизирует, чтобы сосредоточиться на более сложных задачах.
Ещё один важный нюанс – эволюция роли QA в команде. Если раньше тестировщик был своеобразным «контролёром» качества на финальной стадии, то современный подход делает акцент на встроенном качестве (built-in quality). SDET работает бок о бок с разработчиками: пишет для них тесты, учит писать тесты, помогает внедрять лучшие практики (Peer Review, TDD и пр.). Он понимает внутренности приложения и может подсказать, как реализовать ту или иную функцию, чтобы её же было проще протестировать.
Таким образом, хороший SDET повышает общий уровень инженерной культуры в проекте. Недаром наиболее опытных автоматизаторов часто выделяют в отдельные роли – архитекторов автоматизации, консультантов или лидов команд качества. Их вклад выходит за рамки написания тестов – они строят экосистему, где качество обеспечивается коллективно, а не держится на одном человеке.
Как распознать «пускателя»
Допустим, вы менеджер или тимлид, который хочет усилить команду автоматизации. Резюме у всех кандидатов красивые: Selenium, Jenkins, 100500 автотестов… Как понять, кто из них действительно автор, а кто приукрасил опыт? Здесь помогут правильные вопросы на собеседовании. Стоит попросить соискателя рассказать, какой фреймворк для тестов он разрабатывал, с какими сложностями столкнулся и как их решал. Настоящий SDET с горящими глазами опишет, как интегрировал тесты в CI, как реализовал параллельный запуск, как выбирал между REST и UI для проверки определённой функции.
У «пускателя» же ответы будут расплывчатыми: он никогда не строил систему сам, поэтому говорит общими фразами. Полезно дать кандидату небольшое практическое задание – написать простой автотест на выбор. Тот, кто только запускал чужие скрипты, начнёт путаться даже в базовом синтаксисе. Зато инженер-разработчик быстро набросает решение и, возможно, предложит улучшения. Как советуют опытные тест-лиды, попросите автоматизатора запустить свои тесты прямо здесь и сейчас – и многое станет ясно.
Конечно, многое зависит от уровня позиции. Juniors в автоматизации обычно и приходят учиться – никто не ждёт, что вчерашний студент мгновенно построит идеальный фреймворк. Зато хорошего middle уже отличает проактивность: он не ограничится запуском по шаблону, а всегда готов добавить от себя новые тест-кейсы и улучшения. Ну а Senior SDET – это вовсе на вес золота.
Такой эксперт, по сути, совмещает три роли: разработчика, тестировщика и немножко DevOps. Он пишет код на уровне сильного мидла-разработчика, знает современные инструменты тестирования, думает о поддерживаемости и постоянно держит в голове всю картину качества продукта. Неудивительно, что оплата труда автоматизаторов нередко вдвое выше, чем у мануальных тестеров, а спрос на них растёт двузначными темпами ежегодно (источник simbirsoft.com).
Вывод? Если вы сами стремитесь в QA-автоматизацию – делайте упор на настоящее инженерное мастерство. Учите языки программирования, копите опыт в разработке, понимайте принципы тест-дизайна. Без этого легко застрять на уровне «запускателя» чужих тестов и обнаружить, что перспективы туманны. Ну а бизнесу и руководителям проектов важно трезво оценивать компетенции своих QA-инженеров.
Автотесты ради автотестов не нужны – нужны люди, способные их грамотно создать и внедрить. Настоящий SDET экономит компании время и деньги, повышает надёжность продукта и ускоряет выпуск новых релизов. В то время как номинальный автоматизатор без навыков программирования, увы, может лишь создавать видимость прогресса. Различать этих специалистов – значит, вкладываться в реальное качество, а не в иллюзию. И, как показывает практика, рынок всё лучше учится видеть эту разницу.