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

Итоги

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

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