Интро

Я Даниил Тетюшин, 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 процессов. К чему это привело - расскажу в следующем посте.

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

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

Как геймификация прокачала нашу QA команду

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

Что мы получили за три месяца:
- Скорость автоматизации взлетела почти в 2 раза;
- Автотестов написали на 119% больше;
- Вся команда, до последнего, занялась автоматизацией.

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

Мораль проста: не бойтесь рисковать, качайте мозги и ломайте систему своими инновациями.

Джунов по осени считают

Осень, холод — все возвращаются из отпусков, наевшись в модных рестиках, и заходят в свои съёмные квартиры, смотрят на цены и ипотеку под 30%, осознавая и унывая: «пора рубить бабло». В крупных компаниях тем временем вовсю идет оценка эффективности команды — смотрят, кто тащит и ему надо дать денег, а кто создаёт видимость и надо попрощаться.

Performance Review

Когда-то, лет 5 назад, в Авито рассказали, как упростить процесс оценки — придумали Performance Review. Всех оценивают централизованно: ты пишешь свои достижения, собираешь “ачивки”, и коллеги с руководителями решают, достоин ли ты повышения и денег. Мне, как менеджеру, по началу это очень зашло — экономишь кучу времени и отсекаешь все “хотелки” до следующего периода. Но на практике всё превращается в шоу, где ты не просто пишешь, что сделал, но еще и учишься “продавать” свои успехи — красиво объяснять, почему без тебя компания не справиться.

Геймификация: ачивки без боли

В этом году, когда я запускал геймификацию, до меня дошло, что она автоматом дала команде ачивки по итогам квартала. Кто сколько автотестов написал, кто на каком месте закончил сезон и как это повлияло на покрытие. Теперь Вася джун может спокойно сказать: “Я накатал больше тестов, чем Серёжа синьор!” И это уже реальная ачивка, которую не нужно выдумывать.

Почему это важно?

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

Работать нужно не 8 часов, а головой — особенно сейчас.

Как собрать итоги работы для повышения

Собрать итоги работы бывает сложнее, чем саму работу работать. В Performance Review оцениваются достижения, и с этим боль почти всегда.

Вот топ-5 лайфхаков, чтобы ваши achievements залетели:

1. Пишите про успехи, а не про задачи. Никто не впечатлится “делал свою работу”. Не “тестировал”, а “уменьшил количество багов”.
2. Добавьте метрики. Оцените, насколько вы “молодец”, в цифрах.
3. Краткость рулит. Как и в резюме: больше не значит лучше, без поэм.
4. Привяжите к командным целям. Важно, как ваши успехи повлияли на общие результаты.
5. Покажите, чему научились. Полгода прошли, вы выросли — расскажите, как это помогло в проекте.

“Человек стоит столько, насколько он способен себя оценить” — Франсуа Рабле.

Всем по ляму в секунду, пирожочки, не киснем.