SDET в деле: задачи автоматизаторов на проектах и в чем их отличие от QA Fullstack

Привет, Хабр! Меня зовут Людмила и я SDET-специалист в компании SimbirSoft. На текущем проекте мне приходится выполнять достаточно большой пул обязанностей, связанных не только с автоматизированным, но и с ручным тестированием. Иногда у меня возникает интересный вопрос: действительно ли для этого проекта требуется роль SDET или же заказчику больше подошел бы QA Fullstack при выборе специалиста по автоматизации? А может быть нужны одновременно и SDET и QA Fullstack?

В первую очередь эта статья будет полезна руководителям команд, которые стремятся интегрировать SDET в свой процесс работы, но нуждаются в рекомендациях по первым шагам. Также рекомендую к прочтению данный материал специалистам по тестированию и автоматизации, включая SDET, QAA и QA Fullstack.

SDET vs QA Fullstack

Давайте для начала разберемся, какие обязанности берут на себя SDET и QA Fullstack.

Обязанности QA Fullstack мы уже выясняли тут:

• ручное тестирование функционала;

• ведение тестовой документации;

• составление плана и стратегии тестирования;

• написание и поддержка автотестов;

• выстраивание процесса тестирования на проекте.

Обязанности SDET-специалиста следующие:

• написание и поддержка автотестов;

• настройка CI/CD;

• настройка и поддержка фреймворка для автотестов.

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

Статистика с проектов 

Мне стало интересно, как обстоят дела у коллег из SDET-направления SimbirSoft на их проектах, ведь на своем проекте я чаще выполняю задачи QA Fullstack. Вот что из этого получилось:

Вопрос №1: Занимаетесь ли вы ручным тестированием на проекте?

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

Вопрос №2: Есть ли в вашей команде помимо вас QA/QAA/QA Fullstack?

Оказывается, лишь у четверти опрошенных нет QA в их команде на проекте. Здесь интересно посмотреть, как будут меняться ответы в зависимости от наличия QA.

Вопрос №3: Приходится ли заниматься разработкой тест-кейсов?

На проектах без QA SDET-специалистам приходится самим разрабатывать тест-кейсы – это и подтверждает статистика:

60% опрошенных либо изредка, либо никогда не занимаются разработкой тест-кейсов. Оставшиеся 40% так или иначе занимаются составлением тест-кейсов, хотя обычно это делают QA или аналитики. Одна из причин, по которой SDET-специалистам приходится часто переделывать или даже писать самим тест-кейсы – это то, что чужие тест-кейсы изначально плохо подходят под автоматизацию, либо вовсе не могут быть автоматизированы.

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

Вопрос №4 (утверждение): Тест-кейсы на моем проекте сложно автоматизировать.

Среди коллег, у которых в команде есть хотя бы один QA/QAA/QA Fullstack, 60% так или иначе сталкиваются с проблемами при автоматизации тест-кейсов. Причин может быть несколько, например: тест-кейсы написаны изначально для ручного тестирования; тестируемый функционал сложно поддается автоматизации и т.д.

Так или иначе на практике зачастую находится множество факторов, тормозящих автоматизацию на проекте. По своему опыту могу сказать, что это может быть отсутствие тестовых сценариев или избыточное количество тестовых учеток. Отсутствие QA как такового в команде значительно осложняет жизнь автоматизатору – это факт.

Мнения коллег

На практике сложно отделить QA Fullstack от SDET. Наши коллеги из направлений SDET и QA поделились своими мнениями в этом каверзном вопросе.

Дарья, SDET-специалист:

«В моем представлении QAA чаще работают уже с готовыми проектами с автотестами и пайплайнами под них, расширяя имеющуюся тестовую базу. SDET же, помимо тест-дизайна и непосредственного написания автотестов, готов заняться инфраструктурой. Может сам решить, какие технологии нужны под данную предметную область и поднять проект с автотестами с нуля и настроить CI/CD. Но со своей стороны замечала, что понятия QAA и SDET довольно размыты: в вакансиях и статьях разных авторов их обязанности могут перекликаться друг с другом. Кажется, что название должности не важно, гораздо важнее, чтобы заказчик имел ясное представление, чего он ждёт от сотрудника, чтобы обеспечить понимание обязанностей с обеих сторон. 

На моем проекте сложилось так, что я уже 3 года являюсь единственным представителем направления тестирования в команде. Например, я поднимала проект и настраивала отчеты с нуля, в CI это встраивалось DevOps-специалистами с обсуждением со мной ожидаемого пайплайна. Автотесты пишу я, регресс и анализ отчетов тоже на мне, ручное тестирование провожу также я, но какие-то кейсы могут проверить и аналитики. Но тут важно подсветить, что эффективно тестировать продукт в таком случае будет возможно, только если вся команда нацелена на качество. Это достигается прежде всего за счет хорошо настроенных коммуникаций, где все в курсе того, какие задачи и проблемы сейчас стоят перед продуктом и стараются вместе обсуждать и улучшать процессы. У нас есть чат с заказчиками, где есть вся команда и все отвечают на возникающие вопросы и проблемы с функционалом, а значит, в курсе, что происходит с каждым сервисом».

Кристина, QA-специалист:

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

На моем проекте есть разделение на QA Fullstack и автоматизаторов. Команда автоматизаторов поддерживает весь фреймворк автотестов, анализирует проблемы запусков и прогонов, создает различных ботов для облегчения развертывания. Команда же QA Fullstack занимается тестированием задач, проведением регресса и смоука, а также в процессе всего этого – написанием автотестов».

Салават, SDET-специалист:

«Исходя из моего опыта, такие должности, как SDET и QA Fullstack  имеют довольно размытые границы и разделение является субъективным. Например, на проекте, где я работаю, SDET-специалист в основном взаимодействует с техническими аспектами тестирования, и область задач относится ближе к разработке. В то время как QA Fullstack должен также быть независимым от ручного тестирования и производить полный цикл тестирования самостоятельно, что можно определить, как совмещение manual QA (ручное тестирование) и QAA в одной должности. Таким образом, если разделять эти два понятия, то спектр задач QA Fullstack шире и содержит обязанности SDET + manual QA.

В данный момент у нас имеется четкое разделение в работе: manual QA специалисты занимаются созданием тестовых артефактов и взаимодействуют с релизами, в то время как QAA-инженеры автоматизируют поступившие, чек-листы, занимаются поддержкой и улучшением тестового фреймворка».

Айгуль, QA-специалист:

«Все зависит от компании и проекта, но в моем представлении SDET – это больше разработчик + DevOPS в тестировании, т.е. это специалист, который может написать с нуля плагин, помогающий добавить метрики или данные, необходимые для отчета Allure или, например, написать скрипт, который генерирует специальные тестовые данные для тестирования какой-нибудь функциональности, при этом спокойно может развернуть все необходимые среды, инструменты тестирования внутри команды (может написать свой фреймворк). Я считаю, что SDET-специалисту нужно лучше знать программирование (ООП, алгоритмы, структуры данных и backend-разработку), так как автоматизатором можно быть и с использованием готовых фреймворков для тестирования (например, Robot Framework). Распределение задач происходит всегда по-разному. Например, на моем проекте есть автоматизатор, который пишет автотесты по готовым тест-кейсам. Я же являюсь QA Fullstack, так как на моем подпроекте только началась разработка автотестов. Поэтому задачи для меня появляются по мере свободного времени от ручных задач».

Советы заказчику

Принимая в свою команду SDET-специалиста, заказчик в первую очередь должен четко понимать, чего он ждет от будущего сотрудника. Для SDET приоритетными задачами должны быть создание и поддержка тестового фреймворка вместе с CI/CD, а также автоматизация уже существующих тестов. IT-специалисты выбирают SDET за возможность писать программный код во благо качества продукта, так что не нужно лишать автоматизатора радостей разработки. 

По желанию можно привлечь SDET-специалиста к ручному тестированию: соотношения 80%/20% или 70%/30% автотестов к ручным тестам будут вполне уместны. Ну лучше все 90-100% уделять автотестам

Наилучший вариант – когда в команде есть QA/QA  Fullstack, которые пишут авто- и ручные тест-кейсы. В этом случае SDET занимается поддержкой и улучшением фреймворка автоматизации тестирования, добавляет новые фичи, настраивает CI, помогает разбирать прогоны автотестов. 

Например, в соседней команде одного из проектов моего текущего заказчика процессы автоматизированы настолько, что через CI можно автоматически запустить создание тестового плана с последующим его прогоном и выгрузкой результатов на общий дашборд текущего релиза. Уж не чудо ли, правда?

ВАЖНО, чтобы в команде были четко распределены роли, а также хорошо настроена коммуникация между участниками этой команды: каждый в курсе текущих задач и при возникающих вопросах легко можно найти ответственного, через которого вопрос будет решен.

Отсутствие онбординга на проекте – опасный трюк, который я совсем не советую повторять. SDET-специалиста, как и любого другого специалиста, важно грамотно погрузить в рабочие процессы вашего проекта, познакомить с командой, дать максимальное представление о том, как решаются вопросы, получаются доступы и многое другое. Если в вашей команде никогда не было SDET-специалиста, попросите коллег/знакомых SDET/QA Fullstack из смежных команд провести ему онбординг или просто спросите совета. Так процесс онбординга пройдет быстрее, а работа автоматизатора будет в разы эффективнее, уж поверьте!

В заключение могу сказать, что SDET и QA Fullstack не являются конкурентами, а скорее комплементарными ролями в современной экосистеме разработки программного обеспечения. Выбор между ними – это не вопрос «или-или», а скорее вопрос о том, как лучше всего организовать процесс разработки и тестирования в каждой  конкретной ситуации. Если вопрос выбора между QA-Fullstack и SDET для вас так и остался открытым, более подробно о роли фулстаков мы рассказали здесь. Надеюсь, мнения моих коллег и советы были для вас полезны. А у вас уже есть SDET на проекте?  

Спасибо за внимание!

Больше авторских материалов для SDET-специалистов от моих коллег читайте в соцсетях SimbirSoft – ВКонтакте и Telegram.