14 причин почему вы никогда не найдете SDETа

Cекреты собеседования с архитектором тестирования

Единорога можно легко спугнуть неосторожным движением, а SDETа — неправильным вопросом на интервью. К сожалению, большинство интервью походят на охоту с завязанными глазами: либо вопросы мимо цели, либо осечка. Артем Мельников расскажет, как надо и как НЕ надо, чтобы вы всё-таки нашли его архитектора по тестированию, который сможет сделать тестирование не задачей, а решением.

Меня зовут Артём Мельников и я сходу назову вам 14 причин, почему у вас ничего получается с наймом SDETа.

У меня профильное высшее образование программиста, работаю по профессии с первого курса и сразу же начал с попытки коммерческой разработки на C++ собственной операционной системы. Один из моих пет-проектов: Cloud WebRTC решение, для проведения честных собеседований. А в тестирование я вкатился потому, что стало интересно в этой теме разобраться. С тех пор я уже пять лет работаю в сфере QA и являюсь тем самым мифическим существом вроде единорога — SDET.

В чём проблема с SDET?

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

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

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

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

SDET создаёт некое общее решение, а не просто автоматизирует что-то. И этим решением потом будет пользоваться вся команда, и влиять это решение будет на весь проект целиком.

Надеюсь, мы разобрались, почему SDET — редкий и ценный кадр, которого сложно найти, легко потерять и невозможно забыть. Давайте теперь разбираться, а как, собственно, искать. Расскажу 14 способов и опишу, а стоит ли к ним прибегать.

1. Проверяете энциклопедические знания

Вопросы про очевидные вещи или вещи из учебников — сомнительная практика. Например, знаю ли я, как внутри работает HashMap, на что подразделяется bucket, какие виды бывают и как ведёт себя при garbage collection.

Как делают? Думают, что глубокое погружение = опытный специалист, который глубоко разбирается в теме и сталкивался со сложными задачами на работе.

Что происходит на практике:

Отвечают на такие вопросы без сучка и задоринки четыре типа людей:

1. Реально крутой опытный специалист, который лез глубоко и 100% попадает в ожидания. Победа!

2. «Зубрила», заучивший все термины и теорию, и на любой вопрос отвечает солиднее и структурнее ChatGPT, да ещё и с реальными перефразированными примерами из документаций и гуглинга. Только реальной практики и навыков там мало, это не тот, кого вы ищите. Провал. На 100% не соответствует ожиданиям.

3. Не «зубрила», прошедший уже 20 собеседований. Он просто не может не ответить на этот вопрос, так как точно такой же вопрос был и на других 10 или более. Этот кандидат не соответствует ожиданиям на 50%, так как если бы специалист был слишком низкого уровня, даже спустя 20 повторений, наверняка можно было бы его подловить.

4. Ему подсказывают прямо на собеседовании. Очевидно, что провал.

А не ответить на вопрос может реально крутой опытный специалист, который лез глубоко и 100% попадает в ожидания, но который не помнит.

По итогам такого вопроса мы легко упускаем того, кто нам нужен и получаем неплохую вероятность взять совсем не того, кто нам нужен.

Как надо? Просто этот вопрос не нужен. Смело вычёркивайте.

2. Спрашиваете про паттерны проектирования

Это когда спрашивают про паттерны проектирования и 5 принципов SOLID. Вы серьёзно? Какие SOLID, вы вообще видели, как выглядят фреймворки автоматизации и где там SOLID, это редкость! Вопрос нерелевантный.

Как делают? Ожидают, что кандидат подробно расскажет о каждом из них. Зачем — не знают сами.

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

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

3. Не спрашиваете о метриках

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

Как делают? Зачастую этот вопрос совсем упускают, но те кто спрашивают — уже молодцы.

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

Задайте интересный вопрос: есть таблица с количеством тестов, количеством багов и время прохождения тестов. И вот количество тестов изменилось несущественно, а время прохождения выросло, куда копать?

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

4. Не спрашиваете про поддержку актуального тестового покрытия

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

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

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

5. Даёте задачи с абстрактным кодом вместо реального

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

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

Как надо? Чётко опишите задачи и предоставьте РЕАЛЬНЫЙ контекст, в котором кандидат будет работать. Вместо простого показа кода, попросите его предложить решения или улучшения. Например, так: вот фрагмент нашего фреймворка автоматизации. Какие изменения вы бы внесли для повышения его эффективности?

6. Спрашиваете алгоритмы

Не нужны решения алгоритмов, уж тем более автоматизаторам. Дайте вместо этого базовый набор данных, доступ к Google, и пусть за 5-10 минут составит пару тест-кейсов, а потом попросите их автоматизировать. Желательно подготовить для этого демо-приложение, в котором он реально будет взаимодействовать, а не псевдоабстрактный код, и не забудьте заложить пару проблем. Лучше потратить час на это, чем на алгоритм. Это менее стрессово для тех, кто реально пишет код и тесты каждый день, и гораздо интереснее.

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

Как надо? Предоставляйте практические задания, связанные с автоматизацией тестирования. Например, попросите создать автоматизированный тест-кейс для регистрации нового пользователя в нашем демо-приложении. Дайте доступ в Google, Swagger, и сам кусок кода.

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

7. Оцениваете кандидата только по прошлому опыту

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

Как надо? Оценивайте кандидата по его ТЕКУЩИМ навыкам и готовности учиться новому. Задавайте вопросы о том, как он решает проблемы, какие новые технологии изучал недавно и как применяет их в работе. Это позволит понять, насколько кандидат способен адаптироваться и развиваться вместе с компанией, а ещё насколько он горит своей работой.

8. Не даёте на оценку архитектурное решение

Архитектура — это фундамент, пусть напишет архитектуру фреймворка. Дайте ему заранее подготовленную архитектуру, пусть скажет, какие минусы видит.

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

Вы прямо на собеседовании при разговоре с толковым SDETом сможете получить value для вашего текущего проекта, куски можно менять. Вопросы об архитектуре тоже. И уже получить income.

9. Забываете спросить о многопоточности

Знание многопоточности — важный навык для SDET. Если вдруг кандидат говорит "я об этом только слышал", это red flag в 99% случаев.

Как надо? Включите вопросы о многопоточности и параллельном выполнении тестов. Например: "как вы реализуете параллельное выполнение тестов в вашем фреймворке?" Или "какие проблемы возникают при работе с многопоточностью и как вы их решаете?" Дайте практический пример, где многопоточность работает не так как ожидалось, пусть кандидат предложит практические реальные решения.

10. Не считаете, что неведение о Profiler — это красный флаг

Если кандидат не знает что такое Profiler, это тоже red flag. Автотесты могут потреблять больше ресурсов, чем продакшн-окружение, поэтому кандидат должен понимать и уметь оптимизировать существующий код.

Как надо? Задавайте вопросы о профилировании и оптимизации тестов. Например: "как вы выявляете и устраняете узкие места в производительности ваших автотестов?" Или "какие инструменты вы используете для профилирования тестового кода?"

11. Забыли про пирамиду тестирования

Пирамида тестирования — основа для каждого SDET. Это фундаментальная концепция, на которую следует опираться, стремясь к идеальному миру. Это одновременно и план развития фреймворка и life check текущего процесса тестирования.

Как надо? Попросите кандидата объяснить пирамиду тестирования и как он реализует её в своих проектах. Пусть расскажет про Mockи, Stubы, про то как он делал интеграции.

12. Упускаете навыки CI/CD

Умение пользоваться CI/CD на уровне продвинутого юзера — основа SDET в нашем мире. Если кандидат никогда этого не делал, то перед вами обычный автоматизатор.

Как надо? Спросите его, какие виды пайплайнов он писал, что такое триггеры, как с этим работать. Дайте пару проблем, пусть словами опишет решение.

13. Не слушаете вопросы кандидата

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

14. Отдали процесс на откуп HR

Удалите из процесса HR, которые не разбираются в деле. Отправляйте таких кандидатов после базового скрининга на техническое собеседование максимально быстро.

Выводы

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

Я же хочу приходить на проект и общаться с компетентным человеком. А в реальности происходит ерунда: сидят автоматизаторы и спрашивают вопросы из википедии и документации. Это бесит. Мне бы очень хотелось, чтобы в нашем русском IT смотрели на решения, которые принимает программист-тестировщик как инженер и архитектор, а не задавали глупые вопросы и получали не менее глупые ответы.

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