Интро

Я Даниил Тетюшин, 8 лет руковожу командами качества в компаниях с много миллионной аудиторией и миллиардной выручкой. В прошлом руководил в СберЗдоровье и Юле, где так же внедрял OKRы и Perfomance Review. А стартовал свой путь в it почти 14 лет назад - системным аналитиком, хоть и отучился на математика-программиста. Сейчас работаю над парочкой своих проектов - какие продам, какие просру, узнаем позже.

О чем канал:

- Как строить крутую команду качества: кого стоит нанимать, а кого увольнять.
- Управление командами: как не сгореть и меньше работать.
- Целеполагание: зачем OKR, а когда KPI.
- Performance Review: путь истинный или в один конец - как правильно;
- Токсики и троечники: психология команд и инженеров.

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

Личка: @dtetyushin

Почему Fullstack QA - это будущее? Мой опыт из стартапа

В 2019 году я работал в стартапе в Москве, который создавал аналог Twitch. Задача была не только в том, чтобы быстро запуститься и не обосраться, но и катить релизы пачками — добавлять удачные фичи и убирать те, что не зашли.

Спойлер - продукт закрылся в прошлом году. Не зашел.

Когда у тебя 20 релизов за спринт, тебе 20 раз нужно протестировать весь продукт - это долго и дорого. Это был не наш путь. Набирать QA на каждую платформу - web, mobile и backend и потом пытаться "танцевать" с ними вокруг совместного тестирования — это был путь в никуда. Нам нужны были QA, который могли бы протестировать продукт целиком, понимая, как работает каждый сервис, будь то фронт или бэк, и стать единой точкой входа по фиче.

В тот момент я не помню ни одной вакансии на hh с такими требованиями, что внушало «оптимизм». Я вдохновлялся опытом Facebook и Google — они уже нанимали и обучали подобных специалистов, а значит можно и попробовать.

Если кратко - команду собрали, обучили, но не без факапов конечно (об этом еще будет пост) и проект запустился. Катили много и приучили Продактов, что за свежей инфой о релизах можно приходить сразу к QA - он все знает 😁

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

Автоматизируй или уходи

За свою карьеру я видел множество изменений в роли QA инженеров, но если всё это обобщить, можно сказать: «Ты повышаешь качество и автоматизируешь свою работу». Здесь подходит фраза: «Если кто-то не дорабатывает, кто-то перерабатывает». Если вы не автоматизируете свои тест-кейсы, это должен делать кто-то другой. Но зачем им это, если каждый инженер должен быть самодостаточен и уметь автоматизировать?

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

За годы я видел лишь пару примеров, когда из «засидевшихся» ручников выходили уверенные автоматизаторы. Это доказывает правило через редкие исключения.

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

SDET. Часть 1. Разработчик или тестировщик?

Ранее я писал, кто такой QA в 2024 и что от него ждут. Тестирование продукта от бэкенда до клиента и автоматизация - это база. А вот дальше расти интересней, один из вариантов - SDET.

SDET — Software Developer Engineer in Test, или, говоря проще, разработчик в тестировании. Впервые прочитал о роли в 2017 году в статье Microsoft, где они рассказывали о сдэтах в команде Exchange как о следующем этапе развития тестировщика.

Да, SDET в первую очередь тестировщик. Он знает основы тестирования, может разработать тест-план, провести ревью тестовой модели и написать автотест любой сложности, но это не его ключевая задача - на это есть QA. В задачи SDET-ов в моих командах входит:
- Делать стабильную тестовую инфру(мобильные фермы туда же);
- Интегрировать тесты в CI/CD;
- Разрабатывать фреймворки автотестов;
- Создавать иные инструменты автоматизации под задачи команды.

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

Однако, есть нюанс с поиском. Я много раз собесил кандидатов с "лычкой" SDET с запросом 500к в секунду, но при этом не могли ответить за основы тестирования. Если вы разработчик, решивший перейти в QA ради повышения зарплаты, вас быстро раскроют. То же самое касается QA, прошедшего пару курсов на степике и почувствовав, что пора😀

За последние 3-4 проекта в моих командах SDET-ами были ребята с опытом в разработке минимум от мидла, которые знали за архитектуру приложения и инфру. Итого минимальные требования к SDET сейчас следующие:
- Senior в QA;
- Senior в автоматизации;
- Middle в разработке (Java/Python);
- Junior в инфраструктуре.

Потребность в таких инженерах в компании обычно говорит о высокой зрелости процессов качества и автоматизации, когда обычных Fullstack QA и DevOps уже недостаточно. Я обычно распределяю их по направлениям, на курирования нескольких команд, решая их задачи и проблемы. Все они также входят в "виртуальную" команду, объединяющих SDET-ов со всей компании.

Зачем нужна виртуальная команда SDET-ов, будет в следующем посте.

Дарю свой +1 билет "для друга" на ближайший Heisenbug в Питере 17-18 октября!

17 октября я буду на сцене Heisenbug в Питере и решил разыграть свой +1 билет для друга. Условия простые:

1. Подпишись на канал @shiftmindset
2. Нажми "Участвую"
3. Дождись 15 октября

В этот день бот-рандомайзер выберет победителя, которому я вышлю билет.

Участников: 10
Призовых мест: 1
Дата розыгрыша: 12:50, 15.10.2024 MSK (завершён)

Победители розыгрыша:
1. Alena Bogdanova - 1mpua2 (переразыгран)

SDET. Часть 2. Команда разработки в QA

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

Да, в идеале было бы классно иметь свою Core команду, которой управлял бы только я. Но реальность такая, что приходится выкручиваться без этого, и тут на помощь и приходит модель «гильдий» от Spotify: сборка инженеров из разных юнитов, работающих на общую цель. У меня получилось что-то похожее: опытные SDET со всех команд и QA которые учатся у старших, а вся гильдия держится на нескольких ключевых ролях:
- Лид SDET, для планирования и координации.
- Арх совет для контроля ключевых решений.
- Решалы за внедрение — старшие ребята, которые пинают свои команды, чтобы новые решения быстро раскатывались.

Как выжить в SDET команде: Несколько лайфхаков

1. Работайте на бизнес и IT. Ваши задачи должны решать конкретные проблемы. Занимаетесь хренью — будьте готовы к тому, что вашу гильдию могут слить. Лучшая защита — это четкая стратегия на год, которая синхронизирована с бизнесом и IT.
2. Планируйте OKR-ы на квартал. Это помогает вам и бизнесу понимать, на что идут ресурсы и как вы будете улучшать процессы. OKR — это уже база для меня с 2017 года и без него вопросов будет гораздо больше, чем ответов.
3. Доверие важнее задач. SDET — это не совсем ваш“ресурс”, это часть своей команды. Так что дружите с Тимлидами, делайте демо, делитесь обновлениями и ходите в барчик по пятницам. Чем больше доверия у продуктовых команд, тем больше свободы у вас для внедрения ваших идей.

Зачем вообще нужна виртуальная SDET-команда?

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

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

Заряжайте лайки, чтобы Даня не ленился писать еще 😀

Как хачапури меня геймификации научил

Дисциплины публиковать 3-5 постов в неделю мне пока не хватает — особенно когда началась суета перед Гейзенбагом в Питере, где я буду рассказывать, как мы SDET командой запустили сервис геймификации. Поэтому вот история о том, как это было.

В декабре 2023 года я совершил весьма дерзкий коммит на нереальные показатели в рамках стратегии качества. Основной фокус был на ускорении автоматизации, конечно же, без потери качества. У меня давно была привычка завышать планку на 50-100%, чтобы создать «режим горящей жопы» — состояние, когда мозги начинают работать иначе, и ты рождаешь что-то новое: процесс, идею или решение, которые никто до этого не делал.

Лето, хачапури и челлендж

Летом того года, будучи под завязку наевшимся хачапури в Грузии, мы с друзьями вдруг решили взвеситься. Увидев результаты на весах, пришло осознание, что пора прекращать этот беспредел и заняться собой. Мы решили сбросить вес, но чтобы было весело, добавили немного игрового азарта. «А что если ограничить время и поставить цель для всех?» — подумали мы. Взяли умные весы, замерили процент жира и решили устроить челлендж: «Сбросить 3% жира за 3 месяца».

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

Идея для QA-геймификации

Теперь вернёмся в декабрь 23-его. На волне успеха от нашего летнего челленджа я подумал: - А что если замутить тоже самое в Куашке? Сделать платформу для геймификации it процессов. К чему это привело - расскажу в следующем посте.

Йоу, всем привет из Питера! Город барчиков, мостов и конференций - как приятно вернуться😀

Не забывая про канал - сегодня будет пост про цифры запуска геймификации, а вот основную историю - услышат участники Гейзенбага