SDET как эволюция QA, или почему автотестов больше недостаточно

Привет, Хабр! Меня зовут Антон Фоломкин, я SDET-инженер в Orion soft. В этой статье я хочу поделиться опытом формирования экспертизы в тестах, которая называется SDET. Проблема качественного тестирования стоит сегодня достаточно остро. Все мы видим сырые продукты, невыловленные баги в привычных приложениях, и часто даже размышляем: «А стоит ли вообще обновляться?». Подобная ситуация сложилась потому, что старые практики тестирования перестают работать в новых условиях. 

Наша компания занимается различными инфраструктурными продуктами — создаем решения для виртуализации, терминального доступа, контейнеризации, управления виртуальной и облачной инфраструктурой, работы с ML/AL. Разрабатывать все это безумно интересно, но долго и сложно. Релизный цикл в среднем составляет полгода, и это значит, что перед выходом каждой новой версии необходимо провести ее комплексное тестирование. Учитывая нарастающую сложность продуктов и их связей между ними, мы решили выращивать в компании тестировщиков нового типа. В этой статье я расскажу подробнее о том, как мы помогаем ребятам становиться SDET-инженерами и что из этого получается.

Кто такой SDET

Если открыть учебник или словарь, то мы узнаем, что SDET — это Software Developer and Engineer in Test — то есть разработчик в тестировании. Из определений в основном следует, что SDET — это человек, который создает для команды разработки дополнительные инструменты, развивает фреймворк, создает тулзы, которыми пользуются как разработчики, так и тестировщики.

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

Если сравнивать SDET и QA-инженера, то здесь разница будет в глубине и широте. Обычно QA-инженеры «живут» отдельно от команды разработки, они проводят ручные тесты и end-to-end автоматизированное тестирование. Но при этом в интеграционные и юнит-тесты они практически не влезают. Другое дело со SDET. Это не только человек, который тестирует продукт, но и напарник разработчика на всех этапах тестирования. То есть, пока разработчики пишут код, SDET проводит код ревью не только на уровне тестов, он проверяет само решение. В идеале он должен не только помочь разработчику распределить тесты по нужным слоям пирамиды тестирования, но и подготовить для команды разработки различные инструменты. SDET также проводит дополнительные исследования и участвует в R&D. То есть такой специалист приносит пользу всей команде.

Но ведь живут же люди без SDET?

Живут, и мы тоже жили. Но по мере роста масштабов отсутствие специалистов такой квалификации приводит к ряду проблем. В частности, это переавтоматизация тестирования, усложнение процессов разработки и ухудшение качества тест-дизайна. Давайте рассмотрим каждый пункт подробнее.

1. Переавтоматизация 

Стремление внедрять автотесты (а оно естественно — не тестировать же все руками), приводит к тому, что большая часть тестов пишется на верхнем слое пирамиды тестирования. Разумеется, автотесты пишутся так, чтобы покрыть всю функциональность, и мы часто получаем типичные проблемы:

• Тесты гоняются очень долго;

• Они становятся нестабильными;

• Автоматизации подвергается все подряд (в том числе, то, что нужно проверять на совершенно другом слое тестов);

• Не всегда понимаем, что на самом нужно автоматизировать и как именно.

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

2. Сложность понимания процессов разработки ПО

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

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

3. Кривой тест-дизайн

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

Говоря про уровни, я имею в виду классическую пирамиду тестирования. Следуя лучшим практикам построения такой пирамиды, необходимо организовывать следующее распределение: end-2-end тестов должно быть минимально, интеграционных — среднее количество, а юнит-тестов — больше всего. 

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

Давайте посчитаем, что делает GitLab, ведь у них есть открытая статистика. Если посмотреть на нее, мы увидим, что на «верхушке пирамиды» Community Edition — 401 тест, white-box тесты — это дополнительные тесты, которые проводятся различными утилитами и просто вручную — их 8362. При этом интеграционных тестов почти 40 тысяч, а Unit-тестов — уже 140 тысяч. 

Такой подход дает оптимальное распределение тестов и баланс между ресурсами и качеством продукта.

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

Откуда появились SDETы?

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

Но если дать людям с хорошей базой залезать в архитектуру, во внутренние процессы сервисов, в код разработки, в R&D, мы как раз и получим SDET. При этом экспертиза специалиста только укрепляется. И мы не говорим ему: «Ты больше не тестировщик». Наоборот, человек по-прежнему отвечает за качество, но уже на совсем другом уровне. То есть он «еще больше тестировщик», чем раньше.

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

Так это тестировщик или разработчик?

Когда мне доводится обсуждать опыт работы со SDET, практически всегда у коллег возникает вопрос: «Так SDET появляется из разработчика или из тестировщика»? Чтобы ответить на этот вопрос, мне кажется, лучше всего обратиться к классическому подходу моделирования развития навыков. 

Изначально любой специалист находится на стадии I-shape навыка. И поскольку мы говорим сейчас о тестировании, то у любой тестировщик начинает с базовых навыков и знаний по тестированию ПО. 

Однако, развиваясь дальше, каждый человек может стать T-shape — то есть дополнить экспертизу в одном направлении, знаниями и навыками в смежных областях. (Кстати, все без исключения лиды — это T-shaped инженеры). И когда тестировщик становится инженером по автоматизации тестирования, он изучает, как работают инженеры, что делают разработчики. 

Но все это не дает ответа на вопрос: в своей основе идеальный SDET — это разработчик или тестировщик? Я уверен, что и то, и другое. SDET — это M-shaped специалист, который имеет больше одной экспертизы в фундаменте. И на их основе создает что-то новое. 

По классике M-shaped дает человеку следующие характеристики:

• Устойчивость. Сегодня постоянно происходят какие-то потрясения, в коллективе постоянно что-то меняется, привычные процессы могут нарушаться. Но широкая экспертиза позволяет компенсировать происходящие проблемы — сегодня от меня нужно чуть больше навыков тестирования? Хорошо! Завтра я чуть больше разработчик? Тоже нормально!

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

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

Таким образом, мы можем добавить специалисту по тестированию навыки автотеста и привить умения разработчика либо научить разработчика тестированию и аналитике. В любом случае SDET становится M-shaped инженером. 

Опыт нашей команды

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

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

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

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

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

Принципы обучения

Расскажу, как именно происходит обучение. Мы придерживаемся принципа из трех компонентов, которые обеспечивают планомерный рост специалистов.

Shift-left. Смотри шире, подглядывай, что происходит у соседей.

Чтобы понять, как найти баг, нужно разбираться в коде. Для этого можно использовать технический долг, который висит в бэклоге. Там есть фичи, которые требуют разработки. Я не говорю про пользовательские фичи, ответственность за реализацию которых сразу будет высокой. Для обучения SDET можно использовать рефакторинг, разработку, оптимизации. Получая такой опыт, будущие SDET формируют нормальное понимание тест-дизайна. Становясь чуть-чуть разработчиками, они уже через несколько месяцев могут делать код-ревью. 

Следи за своим окружением сам. Если что-то сломал, то почини тоже сам.

Мы занимаемся инфраструктурным ПО, и это наш контекст, который помогает обучению. Основная фишка в том, что наши разработчики и тестировщики работают с собственным железом. Ребята могут разворачивать стенды с чем угодно. Итак, если тебе нужен стенд с LDAP-каталогом… разверни его сам и тестируй! Нужен стенд с какой-то особой версией ОС? Просто берешь и делаешь его! Нужно протестировать MFA? Можешь настроить так, как тебе надо, и проверить, как все работает. Главное — потом почистить стенд за собой. Такой подход распространяется сегодня на всех разработчиков и тестировщиков. Есть даже аналитики, которые справляются сами (но это уже за рамками темы обучения SDET). Так коллеги набираются опыта и не отвлекают лишний раз DevOps.

Спроси, как живут соседи. Вдруг у них можно поучиться.

Когда приходит человек со стороны, мы всегда спрашиваем, как у него строилась работа там, что было лучше и что хорошего он видит в Orion soft. Приведу пример. Однажды у нас появился еще один инженер по тестированию (который уже был крутым SDET — но это скорее исключение). Он регулярно тестировал наш продукт в конфигурации с балансировщиком. Мы, как инженеры инфраструктурного ПО, привыкли к тому, что постоянно тестируем подобные схемы руками. Но ему так сильно это надоело, что новичок написал автоматизацию развертывания стенда ПО в нужной конфигурации — прописал, сколько нужно брокеров, нод и балансировщиков, какие настройки к ним применяются и так далее. Вся команда была просто в восторге, потому что его сервис по автоматизации теперь используется повсеместно. Это стало возможно, потому что мы выслушали обратную связь и поддержали его в написании такого сервиса. Теперь такие практики обмена опытом являются стандартом в нашей команде.

Немного о soft skills

Практика брать специалистов с имеющимися компетенциями и дообучать их на реальном коде оказалась результативной. Теперь у нас в команде есть специалисты SDET, которые работают на стыке технологий и разных направлений — разработка, тестирование, DevOps. Им нужно постоянно со всеми общаться, и поэтому soft skills развиваются у них намного активнее, чем у тех же разработчиков.

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

На сегодняшний день каждая команда выглядит так: тимлид, техлид, скрам-мастер (jira-завхоз), один ведущий лид-тестировщик и его заместитель. Получается 6 разработчиков, на них 1 SDET, а также аналитик и дизайнер — то есть команда из 10 человек. И именно в таком составе мы вернулись к той самой эффективности, которой хотели достигнуть, но уже с гораздо большим запасом прочности по части нагрузки и скорости решения задач тестирования.

Заключение

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