Автор: Гаурав Синх (Gaurav Singh)
Оригинал статьи
Перевод: Ольга Алифанова

Сейчас очень распространено такое название должности автоматизатора, как 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. Это мой взгляд на эту роль, и я убежден, что в статью не вошло множество высокоуровневых деталей. Будем продолжать разговор – дайте знать, если я что-то упустил.

Обсудить в форуме