Интро

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

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

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

Узнавайте куда идет ваша компания

Сидишь, работаешь, за окном уже снег вовсю, а тут твой лид заявляет: «Вася, мы завтра летим в космос, а ты не космонавт, так что, сорян, остаешься на земле». Вопрос «какого, собственно, х… я остаюсь и зачем нам космос?» уже риторический — и задавать его поздно.

У меня не было ни одного проекта или компании, где я бы не сталкивался с моментом, когда внезапно меняется курс, приоритеты или целая команда. Причем по ощущениям всегда ровно в тот момент, когда, кажется, всё наконец-то стабильно. Порой казалось, что все CЕО и директора — просто школьники с биполяркой, которые не могут определиться, чего хотят. Но со временем пришло осознание: с 90% вероятностью план на изменения был, просто я о нем не знал.

Если вы не помогаете стратегии, вы за бортом.

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

Если не хотите, чтобы космические идеи вашего продакта и СЕО застали вас врасплох, начните с того, чтобы спросить своего лида: «Какая у нас IT-стратегия на год?» Если её нет — печально. Если есть — ищите, как вы ей помогаете, или в космос могут полететь без вас.

В любой ситуации — стройте свою стратегию

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

Основные блоки айти стратегии:
- Цели и задачи
- Команда и её развитие
- Техстек и инструменты
- Процессы и автоматизация
- Метрики, как вы измеряете успех

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

Не будь в коконе

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

Но ты не такой. Ты сидишь дома на диване, хомячишь чай с булкой, а реальные проблемы людей для тебя — просто баги в джире. «Саша, тикетов в саппорте за q3 стало больше на 7%». А в этот момент оценщик на морозе, с 3G, загружает минутное 4K-видео работы двигателя в твоё идеально протестированное и pixel-perfect приложение.

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

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

Что должно быть в стратегии QA на 2025 год

Рынок меняется быстрее, чем ты правишь тесты. До конца года всем зрелым ребятам предстоит ежегодное упражнение — формирование стратегии IT и качества на год вперёд. В ней важно учитывать апдейты на рынке — это уже необходимость, а не опция. Собрал для вас ключевые направления, которые стоит добавить в стратегию на 2025 год, если хочешь остаться в игре.

1. Генеративный ИИ для автоматизации
Генеративный ИИ уже вовсю генерит тесты, анализирует данные и находит слабые места, сокращая время тестирования. Microsoft использует ИИ для генерации тестов в продуктах Office, а Meta — для анализа кода и поиска багов. Если ещё не пользуешься, то следующий год — самое время.

2. Комплексная автоматизация
Автоматизация — это не просто набор тестов, а основа стабильности. Полное покрытие — от юнитов до регресса, с интеграцией в CI/CD и регулярным обновлением — делает релизы быстрее и стабильнее. Тот же Amazon тесты интегрируют на каждом этапе разработки, чтобы QA-команда всегда держала качество продукта на уровне.

3. Метрики и аналитика
По ним оценивают ваш прогресс и результаты. Метрики показывают, как QA влияет и почему это важно для бизнеса. Google использует метрики качества кода и покрытия, чтобы принимать решения о релизе. Прозрачные и понятные отчёты, которые видят не только QA, но и руководство, делают вклад команды очевидным и значимым. Если метрики не говорят за тебя — пора их пересмотреть.

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

5. Единое видение и связь с бизнесом
Тестирование — это не гонка за багами, а вклад в цели компании. Создавайте единое видение, где каждый понимает, как его работа помогает бизнесу. Обсуждайте приоритеты, делитесь результатами и показывайте метрики, которые важны не только для QA, но и для руководства. Чем лучше команда понимает, как её работа влияет на компанию, тем меньше вопросов «а зачем нам QA?». В своих проектах именно для этого использую OKR-ы и практику стратегий, чтобы держать фокус и связь.

Это не волшебная палочка, но поможет вашей команде держаться на уровне. В следующем году нас ждёт ещё больше автоматизации и командной работы. Полный текст большого отчёта World Quality Report 2024-25.

Не бойся ломать прод.

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

Страх — яд для команды

Как только в вашей компании появляетя страх наказания или увольнения за «сервисные» действия по примеру неудачного релиза, вы начинаете работать сильно хуже. Даже исследования есть: страх резко снижает когнитивные функции. Как результат все бояться и тупят.

Ответственность за релиз — на всей команде

Релиз — это результат работы всей команды и Тимлида. Вы вместе пилите фичу, вместе её тестите и катите. И никто никогда не хочет намеренно что-то сломать. Так что отвечать за результат должны все — от разработчиков до тимлида, а не один тестировщик (как много где принято).

Дух пиратства — лучший настрой для команды

Команда не должна бояться катить релизы. Напрочь это должно будоражить и подталкивать - только с таким настроем запускаются растут проекты. Конечно, уровень «пиратства» может варьироваться - не везде можно катнуть в пятницу и без тестов. Главное — создать атмосферу, где люди не боятся брать на себя ответственность, ведь страх убивает инициативу.

И помните

Быстро откатанное — упавшим не считается

Всем пятницы и хороших релизов ребятки ❤️