Sdet что это

У SDET — сердце разработчика

Я Software Engineer in Test (SET). Многие не совсем понимают, что это значит. Разработчики часто называют меня «тестировщиком» или «QA», а бывший директор однажды подумал, что я занимаюсь DevOps. Хотя моя работа и охватывает данные области, они не являются моим основным направлением занятости. Давайте я постараюсь прояснить, что значит быть SET.

Кто такой Software Engineer in Test?

Software Engineer in Test (ака Software Development Engineer in Test, SDET) — это разработчик, который занимается разработкой софта для тестирования: инструменты, фреймворки, автоматизированные тесты. SET-ы главным образом фокусируются на автоматизации, чтобы запускать тесты быстро и с возможностью повторов. Автоматизированные тесты это тоже программный продукт: точно так же, как фронтенд-разработчики программируют веб-страницы, а бэкенд-разработчики пишут код для микросервисов, SET-ы пишут автоматизированные тесты, для чего применяются те же практики и навыки написания кода. Я часто говорю, что у Software Engineer in Test сердце разработчика.

Так что, они занимаются просто написанием скриптов для тестирования?

Нет. Никогда не говорите подобного SET. Автоматизация тестирования включает гораздо больше, чем просто «написание скриптов для тестирования». Серьезные решения касательно тестирования требуют серьезной разработки и усилий. Высокоуровневая автоматизация тест-кейсов это обычно только небольшая часть всего. SET-ы ответственны за:

Взаимодействие с разработчиками и владельцами продукта: — участие в планировании и реализации
— ревью продуктового кода
— формулировка тестовых сценариев.
Разработка фреймворков автоматизации тестирования.
Автоматизация тестовых сценариев с использованием фреймворков.
Использование шаблонов проектирования, где это возможно.
Настройка инфраструктуры для запуска тестов: — Запуск тестов на CI/CD.
— Запуск параллельных тестов.
— Запуск тестов с подходящими тестовыми данными.
Настройка дашбордов для предоставления отчетности по результатам тестов в режиме реального времени.
Обучение других лучшим практикам тестирования и обеспечения качества.
Разработка вспомогательных инструментов для ручного и исследовательского тестирования.

Говоря о том, что тестирование это «всего лишь написание скриптов», мы умаляем роль SET и недооцениваем объем работ.

Как появилась эта роль?

Роли «тестировщик» и QA существовали десятилетиями, но роль SET впервые была обозначена в 2000-х, когда стала необходимой и возможной крупномасштабная автоматизация тестирования. Как указано в Википедии, название роли “Software Developer Engineer in Test” (SDET) ввел Microsoft в 2005, и другие IT-компании, например Amazon and Apple быстро подхватили этот термин. Google же использовал для этой же роли термин Software Engineer in Test. Лично я предпочитаю говорить SET просто потому, что оно более лаконичное.

Как эта роль отличается от QA и роли тестировщика?

По моему мнению, роль SET заметно отличается от традиционной роли QA или тестировщика. Тестировщики исторически фокусируются на ручном тестировании и поэтому им не требуются сильные навыки программирования. Их сильными сторонами всегда были знание предметной области, интуиция, нестандартное мышление, навыки планирования тестирования и настройки системы тестирования. И это все безусловно важные, незаменимые навыки. В это время SET-ы живут одновременно в мире как тестирования, так и разработки. Они используют навыки разработчика, чтобы поставить программные решения для проблем тестирования. Для роли SET гораздо более важна автоматизация. В наши дни большинство вакансий, связанных с тестированием, предполагают роль SET; ручные тестовые роли в значительной степени устарели. Тем не менее, потребность в ручном тестировании будет всегда, потому что есть такие проблемы, которые самому человеку обнаружить гораздо легче, чем с помощью скрипта (или интеллектуального агента).

Лично я избегаю использования названий QA и «тестировщик» в отношении себя, поскольку они не в полной мере описывают всё то, чем я занимаюсь. Я также избегаю названия «инженер по автоматизации», поскольку, опять же, оно не включает в себя все задачи, с которыми я имею дело. Я занимаюсь тестированием программного обеспечения как разработчик и поставляю решения для автоматизации с нуля. Я горжусь тем, что являюсь разработчиком, специализирующимся на тестировании.

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

SDET

Тестирование и обеспечение качества | Тестировщик | Radar4site.ru | Сервисы и статьи для тестировщиков

На просторах Интернета я пытался найти ответ на вопрос, кто такой SDET?

SDET (Software Development Engineer in Test) — специалист, инженер, который примерно одинаково хорошо умеет быть разработчиком и тестировщиком одновременно.

Когда я просматривал отличия SDET от тестировщика, я так и не понял, почему они отличаются. Одно дело, между SDET’ом и Junior QA могут быть существенные отличия, но это, на мой взгляд, некорректное сравнение — проводить разницу между тестировщиком, который тестировал только вручную в силу того, что только начинает свой путь в тестировании и специалистом, который умеет хорошо программировать и тестировать одновременно. Зачем делать такие сравнения? Мне не понятно.

На мой взгляд, тестировщик (Quality Assurance, а не Quality Control) вполне может заниматься и ручным тестированием, и автоматизацией тестирования. Но тогда не понятно, чем вообще обычный тестировщик в таком случае будет отличаться от размытого понятия SDET.

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

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

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

Получается, SDET — это не вообще не про тестирование. Это про разработку и поддержку инструментов и инфраструктуры тестирования и написание различных скриптов.

Другой вопрос — чем тогда SDET отличается от автоматизаторов? Но об этом, возможно, поговорим в другой статье.

А пока давайте подискутируем в комментариях — поскольку единого мнения до сих нет, хочется собрать мнения, кто как считает, кто такой SDET и нужна ли эта профессия на рынке? И самое главное — где правда? Кто же такой SDET на самом деле?

Кто ты – Automation Engineer или SDET?

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

Test Automation Engineer

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

Здесь важен опыт именно UI автоматизации и способы решения типовых проблем, вроде правильно дождаться элемента или ввести текст так, чтобы не исчезали буквы. Конечно, нужно еще построить automation solution.

Скорее всего, там будут page objects в каком-то виде и, возможно, на этом все. Очень простое решение с кучей подражания, которое на дистанции приводит к тому, что что-то сделать невозможно, или очень долго из-за ограничения дизайна решения, кроме того, что-то постоянно не работает и зеленые джобы – это праздник. Фиксиш в одном месте – падает в другом. У кого никогда не было такого опыта – поделитесь своей историей ��

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

Так кто же будет начинать? Девелопер? Нет, у него куча работы, ему деливерить надо, вон мануальщик сидит без дела, пусть он и сделает. Мануальщик без опыта (или с очень малым опытом «для себя из любопытства») в программировании и автоматизации с радостью бросается в бой, менеджеры получают результат, который им нравится, нанимаются еще люди. Но основа, заложенная тем же мануальщиком, оказывается не очень хорошей и поэтому нужно все больше и больше людей в поддержку и все это превращается в огромный снежный шар.

Мой первый проект по автоматизации начинался примерно так же, и даже люди, которых потом брали, не имели серьезного опыта с JS (на котором был написан проект). Тогда только появился ES6 и я помню вдохновенный разговор типа «я знаю разницу между map и forEach!». Это были интересные времена �� Поделитесь своим первым опытом в автоматизации, очень интересно!

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

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

Software Development Engineer in Test (SDET)

По-моему, это следующее звено эволюции инженера по автоматизации тестирования. Прежде всего, определимся с целями. Глобально, это та же цель – освободить мануальщиков от рутины регрессии и быстрый отклик девелоперам на их изменения в коде. А вот как того достичь — это уже другая история.

По названию должности понятно, что навыки такого специалиста должны начинаться в первую очередь именно в программировании и направлены на автоматические тесты. Это означает, что специалист может сам определить, к какому уровню пирамиды тестирования относится тест и сам его имплементировал, оставляя UI уровню минимальное количество end-to-end flow.

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

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

Также в обязанности входит изменение кода приложения, если его невозможно или слишком сложно протестировать. Если у нас уже есть такие навыки, то добавить себе локаторы в front-end коде не вызывает затруднений.

У меня было интервью, где front-end девелопер попросил меня написать сложный локатор. Я сказал, что даже не буду с этим возиться, а просто сделаю себе удобный тестовый id в нужном месте. Интервьюер ответил, что мои шансы на офер значительно выросли. На самом деле, именно это – довольно простой скил, значительно упрощающий написание тестов и это кратно быстрее и проще, чем просить девелоперов ставить локаторы.

А теперь перейдем к более сложным вещам, а именно дизайн-архитектуре automation solution. Чем он проще (только page objects на подражании) тем, к сожалению, меньше возможностей и больше сложность в поддержке. А чтобы сделать гибкую систему, которую будет легко поддерживать и расширять, нужно иметь хорошие навыки в программировании. Ну, и поскольку SDET — это полноценный разработчик, он должен решать любые задачи, связанные с тестированием без ограничений.

Необходимые навыки: знание и опыт мануального тестирования, знание и понимание языка программирования на уровне «девелоперы обращаются за помощью», знание и умение правильно применить паттерны программирования, умение писать код так, чтобы его понимали джуны, опыт автоматизации тестирования, понимание front-end/ back-end технологий на уровне «могу писать юнит тесты и фиксировать баги».

Я специально не упомянул о конкретных фреймворках и библиотеках, потому что, зная все вышеперечисленное, усвоить фреймворк для автоматизации уже не так сложно. Единственный момент – фреймворк для front-end. Они обычно значительно сложнее, так что с этим нужно разобраться и, желательно, написать не очень сложное приложение на несколько страниц с использованием различных компонентов, чтобы быстрее и лучше ориентироваться при добавлении локаторов и написании юнит тестов.

Итоги

Задача автоматизатора – написать как можно больше автотестов, тогда как задача SDET – написать как можно меньше тестов, но так, чтобы они принесли как можно больше пользы.
Однажды на собеседовании кандидат на позицию senior сказал, что если бы он знал ответы на мои вопросы, то был бы разработчиком.
Сейчас на украинском рынке для SDET работы меньше, потому что и стоит такой специалист больше и, опять-таки, многим нужно просто набрасывать тесты.
И ответ на главный вопрос: вряд ли профессия автоматизатора когда-нибудь исчезнет, но доля SDET будет постепенно расти. В Украине этот рост может быть несколько быстрее при векторе развития рынка в продукт.

Сравнительная таблица

Навыки	Automation Engineer	SDET
Мануальное тестирование	+	+
Программирование	Базовый/средний уровень	Продвинутый уровень
Фреймворки для автотестов	+	Не обязательно
Опыт UI автоматизации	+	+
front-end/back-end технологии	—	+

Home

Сейчас очень распространено такое название должности автоматизатора, как SDET (расшифровывается, как инженер по разработке ПО в тестировании). Уф! У меня ушло почти семь секунд на то, чтобы полностью это произнести.

Шутки в сторону – эта роль была впервые популяризирована крупными техническими компаниями вроде Microsoft и Amazon, и сейчас ее часто можно встретить в описаниях вакансий по всему миру.

Некоторые компании вроде Google отбросили D в пользу более четкого наименования SET (инженер ПО в тестировании), и, конечно же, многие компании последовали за ним.

Но кто же такой SDET?

Что они делают в команде или проекте?
Какие навыки им необходимы?
Тестировщики ли они?
Разработчики ли они?

Иногда я слышу утверждения вроде «Я инженер-автоматизатор, но хотел бы перейти в роль SDET». Это зачастую означает, что люди нечетко понимают, что на самом деле означает работа в качестве SDET.

Инженеры-джуниоры, новички в отрасли, могут сразу же унаследовать этот титул, присоединяясь к компании – или же инженеры миддл-уровня могут получить его, меняя работу. Это, безусловно, один из способов стать SDET, но что же включает в себя эта роль?

Навыки, необходимые SDET

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

Одно из лучших описаний роли я прочитал в книге «Как тестируют в Google» Джеймса Уиттакера, Джейсона Арбора и Джеффа Каролло.

Инженер ПО в тестировании (SET) – это также роль разработчика, только он концентрируется на тестируемости и общей инфраструктуре тестирования. SET проводит ревью дизайна и пристально оценивает качество кода и риски. Он занимается рефакторингом кода, чтобы тот стал более тестируемым, и пишет фрейморки юнит-тестов и автоматизации. Он полноценно участвует в создании кода проекта, но больше обеспокоен повышением качества и тестового покрытия, а не добавлением функциональности или улучшением производительности. STE также практически стопроцентно занят написанием кода, но делает это во имя качества, а не ради функций, которыми будет пользоваться заказчик.

Близость к роли разработчика

Разберем это утверждение, чтобы самостоятельно сделать более конкретные выводы.

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

Также довольно очевидно, что SDET – это человек, который будет писать множество тестового кода, и должен быть способен легко создавать чистый, хорошо организованный код. Он должен уметь проводить ревью кода, неважно, создан ли этот код коллегой-SDET или SWE (разработчиком).

SDET должен отлично понимать систему, за которую он отвечает, в целом, а также стек ее приложений в контексте своей работы (веб-приложение, мобильное приложение, десктопное приложение или распределенный бэкэнд).

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

SDET можно представить, как Т-инженера или как универсала команды, озабоченного качеством.

Итак, теперь мы понимаем широкий спектр ожиданий от SDET, и вы, возможно, думаете о том, существуют ли конкретные дела, которыми, как правило, занят человек в этой роли, работающий в Agile-команде по разработке ПО.

Ниже перечислены некоторые из них.

Навыки разработки ПО

Способность писать чистый, ясный, поддерживаемый и расширяемый код.
Способность проводить ревью кода или документации, созданной SWE/другим SDET или тест-инженерами, и давать техническую обратную связь.
Создание фреймворков автоматизации, которым легко следовать, и поощрение разработчиков в добавлении тест-покрытия на соответствующем уровне.
Понимание хороших практик разработки фреймворков, их компромиссов, внедрение фреймворков в проекты автоматизации тестирования или разработки инструментов.
Способность создавать фреймворки тест-автоматизации с нуля при необходимости, или значительно улучшать готовые решения.
Анализ пробелов тест-покрытия в юнит и интеграционных тестах, и улучшение покрытия функционального кода.
Понимание техник рефакторинга и паттернов проектирования, понимание, когда их нужно применять для решения проблем.
Создание функциональных E2E тестов для приложения (мобильного, веб, десктоп, API) и нефункциональных кейсов для покрытия производительности API или приложений, вопросов безопасности, доступности, и других проблем качества.
Способность писать заглушки и имитаторы для служб и создавать инструменты, упрощающие процессы разработки.
Создание системы мониторинга и отчетности о результатах автоматизированных тестов, и их эффективное использование для анализа и дебага падений.
Создание общей тест-инфраструктуры и процессов CI/CD, объединяющих разные стеки.
Глубоко размышляет о системе и может предложить стратегию тестирования и автоматизации, помогающую снизить риски заказчика.
Понимает, из чего состоит продукт, знает широкий контекст своей системы.
Улучшает покрытие и поощряет разработчиков в создании большего количества тестов, дабы покрыть имеющиеся пробелы.
Участвует в создании спецификации продукта вместе с менеджером проекта и представителями бизнеса, и способен советовать разработчикам, как с самого начала встроить тестируемость в функциональность.
Использует данные о паттернах пользовательского поведения, чтобы убедиться, соответствует ли продукт своим задачам в ходе использования потребителями.
Выступает как ментор для других инженеров команды.

CI/CD, отчетность

Создание системы мониторинга и отчетности о результатах автоматизированных тестов, и их эффективное использование для анализа и дебага падений.
Создание общей тест-инфраструктуры и процессов CI/CD, объединяющих разные стеки.

Тест-компетентность

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

В чем разница между тест-инженером и SDET?

Вы спросите, чем же SDET отличается от тест-инженера?

Книга вновь дает хороший краткий ответ на этот вопрос.

Тест-инженер (TE) связан с ролью SET, но концентрируется на другом. Эта роль ставит тестирование ради пользователя во главу угла, а разработчиков – на второе место. Некоторые тест-инженеры Google тратят значительное время на создание кода в форме скриптов автоматизации, которые управляют сценариями использования и даже имитируют пользователя. Они также организуют тест-работу SWE и SET, интерпретируют результаты тестирования и руководят выполнением тестов, особенно на поздних стадиях проекта, когда движение к релизу становится более интенсивным. ТЕ – продуктовые эксперты, советники по качеству и риск-аналитики. Многие из них пишут много кода; многие из них пишут лишь чуть-чуть.

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

Ряд общих вопросов и фактов

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

Как насчет инструментов?

Если вы заметили, я пока не упоминал какие-либо специализированные инструменты или фреймворки, и намеренно не заострялся на этом вопросе. На это у меня есть причины J

Это связано с тем, что каждая проблема в разработке ПО уникальна. У нас существуют проблемы различных габаритов, и, как правило, решение сильно зависит от контекста – множества факторов вроде компании, команды, культуры, требований и т. Д.

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

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

Возможно, вы сталкивались с цитатой «Если у вас есть только молоток, все вокруг выглядит как гвоздь».

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

Как насчет языков программирования?

Как SDET, вы должны сначала глубоко изучить один язык программирования – неважно, какой вы выберете, но сделайте выбор и придерживайтесь его какое-то время. Если вам нужны варианты, выбирайте Java, Python или JavaScript – они наиболее популярны, и на них пишется множество продуктов и автотестов.

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

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

Что, если в компании нет роли SDET?

У многих компаний отсутствует такая позиция, как SDET. Возможно, у них есть должности вроде инженера по качеству, QA-инженера, QA-инженера-автоматизатора, тест-инженера, инженера-автоматизатора, и т. д., и т. п.

Открою вам секрет.

Названия должностей не важны.

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

Ранее я писал ряд статей на тему названий должностей и той путаницы, которую они привносят, если неправильно определены в компании, можно с ними ознакомиться:4

Testers identity crisis — QA/QE/AE/SDET/SET/TA? .
The problem with titles for testers

Одинокий SDET в команде?

Еще один распространенный вопрос – что, если я единственный SDET в команде?

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

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

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

Я думаю, что тут есть свои нюансы – возможно, поговорю о них в следующей статье.

Заключение

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