Рынок автоматизированного тестирования — один из самых быстрорастущих в ИТ-индустрии. К 2024 году его объем достигнет планки в 30 млрд долларов. В то же время все больше компаний нанимает инженеров-тестировщиков широкого профиля, которые сопровождают продукт на протяжении всего жизненного цикла. 

Под катом Мария Снопок, руководитель команды тестирования Х5 Технологии, рассказывает о том, кто такие SDET и каким компаниям они нужны, а также делится собственным опытом обучения кадров.

Кто такой SDET

SDET — Software Development Engineer in Test — это специалист, который совмещает в себе навыки разработчика, тестировщика и DevOps. Он принимает участие во всем цикле выпуска программного обеспечения — может даже играть роль рецензента на проектировании архитектуры ПО. В каком-то смысле SDET — это QA-инженер, который захотел развиваться в более техническом направлении. 

Если отличие функционального тестировщика от SDET’a всем более-менее понятно, то отличие SDET’aот автоматизатора не столь явное.

Ниже приведена таблица для сравнения функционального тестировщика, автоматизированного тестировщика и SDET:

Каждая компания предъявляет к SDET’aм свои требования. У нас SDET‘ы пишут автотесты, собирают тестовые фреймворки и инфраструктуру для них — по сути, создают утилиты, которыми может пользоваться любой член продуктовой команды.

Впервые позицию Software Development Engineer in Test ввели в Microsoft еще в начале нулевых, в Google, в свою очередь,  придумали свое название для этой роли — Software Engineer in Test (SET). Сейчас таких специалистов нанимают другие крупные компании вроде Amazon и Apple, Facebook и Gitlab. Спрос на позицию SDET’а у нас в стране достаточно высок, однако, проанализировав рынок вакансий в нашей стране, такие выводы сделать сложно: количество открытых вакансий на позицию SDET’а на крупных ресурсах по поиску вакансий на удивление небольшое. Связано это с тем, что должность SDET, как таковая, у нас в стране встречается редко, а роль SDET’а выполняют специалисты в других должностях – Специалист по тестированию, Auto QA, QA Lead, Тестировщик и т. д. Т. е. по факту ищут SDET’a, а называют его по-другому.

Спрос на позицию SDET’а наблюдается в основном от фирм, занятых в сферах информационной безопасности и разработки. Определенный спрос также присутствует со стороны банковской отрасли и игровой индустрии. Востребованность SDET’ов демонстрируют их зарплаты: hh.ru,  indeed.com

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

Не соглашусь с этим утверждением, у SDET’ов так же, как и у разработчиков/тестировщиков есть ступени для карьерного роста: Middle, Senior, Lead, Manager, Expert. Работа SDET’а может быть не менее творческой, чем у разработчика, при этом не ограничена жесткими сроками. Уровень ответственности также очень зависит от специфики выполняемых задач и масштабируемости реализуемых решений. А вот уровень стресса на этой позиции в разы ниже уровня стресса разработчика и тестировщика.

Нужен или нет

По большей части SDET-специалисты нужны только крупным организациям, штат которых насчитывает сотни и тысячи человек. Они разрабатывают комплексные приложения, состоящие из существенного количества сервисов, за каждый из которых отвечает свое подразделение. В таких условиях SDET’ы играют роль связующего звена, подготавливая базу для девелоперов и QA.<o:p>

Можно выделить основные причины, по которым SDET-специалисты нужны только крупным компаниям:

  1. SDET-специалисты довольно дорогостоящие, не все команды/компании могут позволить себе привлекать таких специалистов.

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

  3. SDET’ам, как правило, интересны сложные и амбициозные задачи, возможность опробовать новые инструменты/технологии – это создает определенные трудности в удержании специалиста, т. к. мелкие компании редко могут позволить себе ставить подобные задачи и иметь обширный современный инструментарий для их решения.

Если говорить о нашей компании, в X5 Group SDET’ы нужны для:

  • разработки автотестов

  • организации и настройки CI/CD пайплайнов

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

  • проработки и оптимизации архитектурных решений тестовых проектов

  • подготовки базовых шаблонных образов и проектов для организации автотестирования на проектах с нуля и пр.

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

Однако все зависит от контекста — нужно смотреть, во сколько обходится ручное тестирование, сколько будет стоить его автоматизация, как часто идут релизы. Рассчитать потенциальную выгоду с учетом всех параметров позволяют специальные калькуляторы ROI, однако для корректной работы им нужны исторические данные по предыдущим проектам. Для стартапа эта информация, скорее всего, будет недоступна.

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

Любопытно, что несколько лет назад Microsoft отказалась от позиции SDET в пользу Combined Engineering, когда разработчики сами тестируют свой код. Замечу, что такой подход вряд ли получится масштабировать на основную массу компаний, потому что Combined Engineering подразумевает очень высокий уровень самоорганизации, личной ответственности и профессиональных навыков, можно сказать, что Microsoft «собирает сливки» из специалистов. 

В любом случае, сегодня на рынке наблюдается недостаток специалистов SDET — как в России, так и за рубежом. Некоторые компании по нескольку лет не могут найти достойного кандидата на эту позицию. Многие участники рынка видят решение проблемы в подготовке собственных кадров — мы в X5 Group тоже стали обучать SDET’ов внутри компании.

Как мы растим кадры

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

  1. Внутренние/внешние тематические курсы (тестирование, разработка, devOPS, Agile и пр.)

  2. Комплексная школа подготовки нужного нам специалиста

  3. Кураторство/менторство

Хочется отметить, что все три направления не работают без достаточной внутренней мотивации самого сотрудника и без закрепления полученных знаний на практике. Нельзя закончить курсы, либо школу: и считать себя полноценным SDET’ом, для этого придется еще попрактиковаться как минимум полгода (хотя встречаются отдельные исключительные кейсы).

Если говорить о внешних тематических курсах, то на сегодняшний момент на рынке онлайн-обучения огромное множество хороших тематических курсов, в числе которых «Погружение в Python» от coursera.org, «Программирование на Python для тестировщиков» и «Selenium WebDriver: полное руководство» от software-testing.ru, «Kubernetes Introduction» от katacoda.com, «Docker» от slurm.io, курсы от practicum.yandex.ru, hyperskill.org, javarush.ru, pythontutor.ru и пр.

Если говорить о внутренних тематических курсах, то это курсы «Python», «SQL», «BigData (Hive + Spark)», «Инструменты разработки» и другиеорганизованные в рамках Цифровой Академии. (Это — наша корпоративная образовательная площадка для развития цифровых навыков сотрудников. Форматы обучения разные — от очных лекций и онлайн-курсов до лабораторий и мастер-классов. Преподавателями выступают как наши коллеги, так и приглашенные специалисты из ведущих университетов и компаний-партнёров).  

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

Таких сотрудников мы отправляем в Школу Автоматизаторов, открытую в рамках Цифровой Академии.

Школа Автоматизаторов входит в школу технических специалистов, которая включает еще школы по Python, Java и DevOps. В Школе Автоматизаторов изучают автоматизацию тестирования на языках программирования Python и Java. Это две отдельные программы, имеющие общую часть, а также отдельные части в разрезе языков программирования. Для Школе Автоматизаторов на Python предполагается дополнительный углубленный курс. 

В предыдущей Школе Автоматизаторов обучение проводилось очно, в рабочее время, домашние задания выполнялись в свободное от работы время. 

В Школе, старт которой мы планируем в сентябре этого года, занятия будут проходить в онлайн-формате. Обучение будет построено на видеороликах и домашних заданиях. Каждую неделю будет доступно 1 или 2 блока занятий (по несколько видео) и домашнее задание. Два раза в неделю вся группа будет собираться с кураторами школы и разбирать возникающие вопросы.

Мы планируем провести базовые курсы до середины декабря. В Базе у нас 12 блоков по каждому направлению. Углубленный курс по Python планируется в январе, чтобы ребята успели усвоить полученную на базовом курсе информацию.

Попасть к нам в школу может любой штатный сотрудник, который обладает знаниями по следующим пунктам:

  • Знание основ Функционального тестирования (цикл разработки ПО, цель тестирования, виды тестирования, описание дефекта)

  • Знание техник тест-дизайна

  • Язык программирования (принципы ООП, основные конструкции, типы данных, процедуры, функции, интерфейсы)

  • Основные команды Git

  • Основы Agile Methodology

  • Agile vs Waterfall

Спектр задач, которые решает SDET, выходит за рамки стандартных навыков тестировщика, поэтому во время подготовки мы делаем упор на разработку — алгоритмы, структуры данных, фреймворки и другие углубленные технические вопросы. Учащиеся закрывают эти темы с помощью сторонних и внутренних курсов, разрабатываемых коллегами. Также поддержку обучающимся оказывают кураторы.

 Школа Автоматизаторов — не единственный проект Цифровой Академии: в рамках этой активности уже были успешно пилотированы Школа аналитиков данных, Школа Scrum-мастеров, Управление цифровыми продуктами и сервисами.

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

Кураторство проходит в формате еженедельных встреч с разбором накопившихся вопросов и составлением плана работ на следующую неделю. Один куратор может одновременно курировать нескольких подопечных.

Не стоит забывать о поддержке Сommunity Auto QA, к которому также можно обратиться за помощью.

 Для специалистов с опытом разработки программа переобучения рассчитана на четыре месяца. У студентов без такого опыта на погружение в тему уходит примерно два года. После курса специалист может продолжить нарабатывать экспертизу и развиваться в своей отрасли — сперва как Senior SDET, затем SDET Team Lead и, наконец, SDET Manager.

Первые результаты, и что пошло не так

Первый поток в Школе Автоматизаторов завершился в декабре прошлого года. 

В программе участвовали сотрудники X5 Group.

Статистика по результатам обучения в школе представлена ниже:

Показатель

Java, чел

Python, чел

Набрали в Школу Автоматизаторов

50

8

Закончили в Школу Автоматизаторов

9

3

Применяют полученные в Школе Автоматизаторов знания на практике

2

2

Стали полноценными SDET после окончания Школы Автоматизаторов

1

1

Результаты получились не самыми впечатляющими — поскольку это был наш первый подобный опыт, мы допустили ряд ошибок, а именно:

  • недооценили важность внутренней мотивации. Многие учащиеся оказались не готовы к трудностям, а также к необходимости выделять время на обучение в школе (домашние задания необходимо было выполнять в свободное от работы время). Мотив для поступления был простой: cтартует интересная школа – почему бы не записаться для общего развития?

  • не учли порог вхождения для обучения в школе и уровень первоначальной подготовки«школьников». Для некоторых предлагаемые темы показались слишком сложными. 

  • попытались осветить максимум, в итоге уроки получились поверхностными. Мы провели анализ образовательной программы и поняли, что попытались охватить слишком большое количество топиков. В итоге уроки получились поверхностными, а практика отошла на второй план. Такой подход (вширь, а не в глубину) имеет право на жизнь, но только в том случае, когда ученики самоорганизованы, мотивированы и способны самостоятельно изучать дополнительные материалы за пределами курса.

  • мало внимания уделили практике. Без достаточного количества практических заданий ценность курса невысока. 

  •  не учли необходимость своевременного закрепления полученных знаний в рамках текущей работы. Пример из жизни: ученик закончил школу, полный энтузиазма вернулся в продукт с наполеоновскими планами внедрить автоматизацию тестирования на продукте, а там его ждала ручная работа с загрузкой 110%. Никто не позаботился о том, чтобы разгрузить сотрудника и дать ему возможность применить то, чему он научился. Энтузиазм угас, знания позабылись.

Мы обязательно учтём этот опыт и будем улучшать образовательную программу. Вот что мы планируем делать.

Планы на будущее

В первую очередь планируем повышать качество цифровых продуктов компании за счет развития культуры тестирования в командах. Мы популяризуем роль SDET и привлечем к ней внимание специалистов как внутри компании, так и за её пределами. 

Мы планируем трансформировать образовательную программу Школы Автоматизаторов следующим образом:

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

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

  • мы разбили курс по Python на 2 части: базовый и углубленный, чтобы иметь возможность глубже осветить важные для нас моменты.

  • в новом курсе мы стараемся сделать одинаковый упор как на теоретическую, так и на практическую часть.

  • мы будем проводить разъяснительные беседы с DM и PO на тему изменения состава и объема обязанностей учащегося после окончания школы, а также на этапе зачисления в школу уточнять возможность применения полученных навыков в продукте. 

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

Комментарии (5)


  1. FForth
    31.08.2021 18:39
    -2

    А, не рассматривали ли возможность применения программ типа nncron в вопросах малой автоматизации тестирования?

    Может, в рамках ваших задач и структуры тестирование использование такого решения сэкономит Вам кучу денег.

    Ну или на «крайняк» использование AutoIt :)

    P.S. Python же вроде очень тормознутый язык для использования, а в бизнесе основное время-деньги или уже не так?


    1. lllamnyp
      01.09.2021 05:22
      +1

      Python же вроде очень тормознутый язык

      В данном случае вы оптимизируете не там, где узкое место. Затраты интерпретатора дают мизерный вклад в общее латенси в большинстве юз-кейсов.


    1. ole325
      07.09.2021 12:22

      AutoIt это про пощелкать, с этим он более менее справится (кстати в web не всегда), а вот validation на нем делать очень не очень, в отличии, например, от Ranorex Studio, где порой достаточно пары кликов. Так же Ranorex никак не решит вопросы запуска самих тестов, развертывания виртуалки, выгрузки отчетов.


  1. DolgoarshinnykhL
    09.09.2021 11:10

    Спасибо за статью! Появились некоторые вопросы по ней:

    1) на мой взгляд, к целям SDET-специалиста стоит добавить "налаживание процесса тестирования и обеспечения качества в команде" - это одна из основных "фишек". Она позволяет в т.ч. подтянуть недостаточно зрелые команды ( с точки зрения процессов обеспечения качества) до приемлемого уровня. Как пример из статьи - разработка унифицированной библиотеки. Разработать библиотеку и внедрить её грамотное использование на нескольких проектов - совершенно разные задачи.

    2) как замерялись уровни стресса специалистов разных направлений? Меняя в команде вредные устоявшиеся процессы в "удачных" случаях уровень стресса будет на загляденье высок. Как по мне, метрика сравнения довольно странная


    1. X5RetailGroup Автор
      22.09.2021 12:29

      1) Безусловно, в случае если команда незрелая и в команде нет специалиста, отвечающего за организацию и внедрение процесса тестирования, эти задачи также ложатся на плечи SDET’а. Разумеется, эти задачи имеют первостепенную важность. Но, как правило, отправлять SDET’а в совсем незрелую команду неразумно (можно сжечь специалиста дотла).

      2) “Удачные” случаи – это статистические выбросы, их нужно исключать из общей выборки. Уровень стресса зависит от характера выполняемых задач. У SDET’а, в большинстве своем, задачи не имеют жестких дедлайнов и не приводят к блокирующим и критичным ошибкам в промышленной среде, отсюда меньше стресса.