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 из разных команд.
Когда нет возможности создать отдельную команду, виртуальная — это не просто костыль, а настоящий драйвер. Вы получаете ресурсы для разработки, а ваши решения идут на пользу всей компании. И в целом я считаю это даже лучше, чем отдельная платформа-команда, у которой обычно мало погружения в боли продуктовых команд и они оторваны от бизнеса.
Заряжайте лайки, чтобы Даня не ленился писать еще 😀
Итак, мы уже разобрались: SDET — это не просто QA с джавой, а реальный разработчик с солидными навыками тестирования. SDET-ы — ребята, которые шарят и в коде, и в тестах, а это сразу выводит их на другой уровень. Но боль наступает когда их надо объединить и синхронизировать, если они раскиданы по разным командам. Обычный QA занимается багами и функционалом, а SDET больше копают в сторону автоматизации и инфраструктуры, лишь изредка влезая в продуктовые задачи, а значит генерит много велосипедов будучи без присмотра.
Да, в идеале было бы классно иметь свою Core команду, которой управлял бы только я. Но реальность такая, что приходится выкручиваться без этого, и тут на помощь и приходит модель «гильдий» от Spotify: сборка инженеров из разных юнитов, работающих на общую цель. У меня получилось что-то похожее: опытные SDET со всех команд и QA которые учатся у старших, а вся гильдия держится на нескольких ключевых ролях:
- Лид SDET, для планирования и координации.
- Арх совет для контроля ключевых решений.
- Решалы за внедрение — старшие ребята, которые пинают свои команды, чтобы новые решения быстро раскатывались.
Как выжить в SDET команде: Несколько лайфхаков
1. Работайте на бизнес и IT. Ваши задачи должны решать конкретные проблемы. Занимаетесь хренью — будьте готовы к тому, что вашу гильдию могут слить. Лучшая защита — это четкая стратегия на год, которая синхронизирована с бизнесом и IT.
2. Планируйте OKR-ы на квартал. Это помогает вам и бизнесу понимать, на что идут ресурсы и как вы будете улучшать процессы. OKR — это уже база для меня с 2017 года и без него вопросов будет гораздо больше, чем ответов.
3. Доверие важнее задач. SDET — это не совсем ваш“ресурс”, это часть своей команды. Так что дружите с Тимлидами, делайте демо, делитесь обновлениями и ходите в барчик по пятницам. Чем больше доверия у продуктовых команд, тем больше свободы у вас для внедрения ваших идей.
Зачем вообще нужна виртуальная SDET-команда?
Эта структура закрывает множество болей, которые мучают любую крупную компанию:
- Общие решения по автоматизации, которые работают для всех.
- Единая инфраструктура тестирования, чтобы всё не развалилось.
- Кросс-командные код- и тест-ревью для QA (да-да, без этого никак).
- Обмен фишками и инструментами между юнитами.
- И самое важное — обучение QA из разных команд.
Когда нет возможности создать отдельную команду, виртуальная — это не просто костыль, а настоящий драйвер. Вы получаете ресурсы для разработки, а ваши решения идут на пользу всей компании. И в целом я считаю это даже лучше, чем отдельная платформа-команда, у которой обычно мало погружения в боли продуктовых команд и они оторваны от бизнеса.
Заряжайте лайки, чтобы Даня не ленился писать еще 😀
👍11❤5
Как хачапури меня геймификации научил
Дисциплины публиковать 3-5 постов в неделю мне пока не хватает — особенно когда началась суета перед Гейзенбагом в Питере, где я буду рассказывать, как мы SDET командой запустили сервис геймификации. Поэтому вот история о том, как это было.
В декабре 2023 года я совершил весьма дерзкий коммит на нереальные показатели в рамках стратегии качества. Основной фокус был на ускорении автоматизации, конечно же, без потери качества. У меня давно была привычка завышать планку на 50-100%, чтобы создать «режим горящей жопы» — состояние, когда мозги начинают работать иначе, и ты рождаешь что-то новое: процесс, идею или решение, которые никто до этого не делал.
Лето, хачапури и челлендж
Летом того года, будучи под завязку наевшимся хачапури в Грузии, мы с друзьями вдруг решили взвеситься. Увидев результаты на весах, пришло осознание, что пора прекращать этот беспредел и заняться собой. Мы решили сбросить вес, но чтобы было весело, добавили немного игрового азарта. «А что если ограничить время и поставить цель для всех?» — подумали мы. Взяли умные весы, замерили процент жира и решили устроить челлендж: «Сбросить 3% жира за 3 месяца».
Идея зашла настолько круто, что к нам присоединились ещё несколько ребят и девчат. Мы создали чатик в телеграме, где делились результатами и историями как идет процесс. Правило было суровое - проигравший оплачивает ужин победителям в их любимых ресторанах 😀
Идея для QA-геймификации
Теперь вернёмся в декабрь 23-его. На волне успеха от нашего летнего челленджа я подумал: - А что если замутить тоже самое в Куашке? Сделать платформу для геймификации it процессов. К чему это привело - расскажу в следующем посте.
Дисциплины публиковать 3-5 постов в неделю мне пока не хватает — особенно когда началась суета перед Гейзенбагом в Питере, где я буду рассказывать, как мы SDET командой запустили сервис геймификации. Поэтому вот история о том, как это было.
В декабре 2023 года я совершил весьма дерзкий коммит на нереальные показатели в рамках стратегии качества. Основной фокус был на ускорении автоматизации, конечно же, без потери качества. У меня давно была привычка завышать планку на 50-100%, чтобы создать «режим горящей жопы» — состояние, когда мозги начинают работать иначе, и ты рождаешь что-то новое: процесс, идею или решение, которые никто до этого не делал.
Лето, хачапури и челлендж
Летом того года, будучи под завязку наевшимся хачапури в Грузии, мы с друзьями вдруг решили взвеситься. Увидев результаты на весах, пришло осознание, что пора прекращать этот беспредел и заняться собой. Мы решили сбросить вес, но чтобы было весело, добавили немного игрового азарта. «А что если ограничить время и поставить цель для всех?» — подумали мы. Взяли умные весы, замерили процент жира и решили устроить челлендж: «Сбросить 3% жира за 3 месяца».
Идея зашла настолько круто, что к нам присоединились ещё несколько ребят и девчат. Мы создали чатик в телеграме, где делились результатами и историями как идет процесс. Правило было суровое - проигравший оплачивает ужин победителям в их любимых ресторанах 😀
Идея для QA-геймификации
Теперь вернёмся в декабрь 23-его. На волне успеха от нашего летнего челленджа я подумал: - А что если замутить тоже самое в Куашке? Сделать платформу для геймификации it процессов. К чему это привело - расскажу в следующем посте.
👍11
Как геймификация прокачала нашу QA команду
Вдохновившись спорт челленджем, мы решили замутить такое же, но для QA. Запустили платформу, где все писали автотесты и выполняли еженедельные задания, а результаты шли в общие рейтинги. Хайп поднялся на всю компанию, что мы решили об этом рассказать в Питере на Гейзенбаге.
Что мы получили за три месяца:
- Скорость автоматизации взлетела почти в 2 раза;
- Автотестов написали на 119% больше;
- Вся команда, до последнего, занялась автоматизацией.
Проект завершился эпичным большим звонком с поздравлениями и мерчем для победителей. Все в восторге. А когда команда довольна — это лучшая награда.
Мораль проста: не бойтесь рисковать, качайте мозги и ломайте систему своими инновациями.
Вдохновившись спорт челленджем, мы решили замутить такое же, но для QA. Запустили платформу, где все писали автотесты и выполняли еженедельные задания, а результаты шли в общие рейтинги. Хайп поднялся на всю компанию, что мы решили об этом рассказать в Питере на Гейзенбаге.
Что мы получили за три месяца:
- Автотестов написали
- Вся команда, до последнего, занялась автоматизацией.
Проект завершился эпичным большим звонком с поздравлениями и мерчем для победителей. Все в восторге. А когда команда довольна — это лучшая награда.
Мораль проста: не бойтесь рисковать, качайте мозги и ломайте систему своими инновациями.
❤10
Джунов по осени считают
Осень, холод — все возвращаются из отпусков, наевшись в модных рестиках, и заходят в свои съёмные квартиры, смотрят на цены и ипотеку под 30%, осознавая и унывая: «пора рубить бабло». В крупных компаниях тем временем вовсю идет оценка эффективности команды — смотрят, кто тащит и ему надо дать денег, а кто создаёт видимость и надо попрощаться.
Performance Review
Когда-то, лет 5 назад, в Авито рассказали, как упростить процесс оценки — придумали Performance Review. Всех оценивают централизованно: ты пишешь свои достижения, собираешь “ачивки”, и коллеги с руководителями решают, достоин ли ты повышения и денег. Мне, как менеджеру, по началу это очень зашло — экономишь кучу времени и отсекаешь все “хотелки” до следующего периода. Но на практике всё превращается в шоу, где ты не просто пишешь, что сделал, но еще и учишься “продавать” свои успехи — красиво объяснять, почему без тебя компания не справиться.
Геймификация: ачивки без боли
В этом году, когда я запускал геймификацию, до меня дошло, что она автоматом дала команде ачивки по итогам квартала. Кто сколько автотестов написал, кто на каком месте закончил сезон и как это повлияло на покрытие. Теперь Вася джун может спокойно сказать: “Я накатал больше тестов, чем Серёжа синьор!” И это уже реальная ачивка, которую не нужно выдумывать.
Почему это важно?
Рынок IT в России перегрет, и быть просто хорошим уже не прокатит. Компании ужесточили подход к найму и бюджету: проекты и зарплаты замораживаются, и если ты не показываешь реальную ценность, можешь легко оказаться в списке сокращений. В такой период важно показывать измеримые результаты и свою эффективность. Но как и любой кризис — это отличный момент, чтобы расти, развиваться и опережать «залетных».
Работать нужно не 8 часов, а головой — особенно сейчас.
Осень, холод — все возвращаются из отпусков, наевшись в модных рестиках, и заходят в свои съёмные квартиры, смотрят на цены и ипотеку под 30%, осознавая и унывая: «пора рубить бабло». В крупных компаниях тем временем вовсю идет оценка эффективности команды — смотрят, кто тащит и ему надо дать денег, а кто создаёт видимость и надо попрощаться.
Performance Review
Когда-то, лет 5 назад, в Авито рассказали, как упростить процесс оценки — придумали Performance Review. Всех оценивают централизованно: ты пишешь свои достижения, собираешь “ачивки”, и коллеги с руководителями решают, достоин ли ты повышения и денег. Мне, как менеджеру, по началу это очень зашло — экономишь кучу времени и отсекаешь все “хотелки” до следующего периода. Но на практике всё превращается в шоу, где ты не просто пишешь, что сделал, но еще и учишься “продавать” свои успехи — красиво объяснять, почему без тебя компания не справиться.
Геймификация: ачивки без боли
В этом году, когда я запускал геймификацию, до меня дошло, что она автоматом дала команде ачивки по итогам квартала. Кто сколько автотестов написал, кто на каком месте закончил сезон и как это повлияло на покрытие. Теперь Вася джун может спокойно сказать: “Я накатал больше тестов, чем Серёжа синьор!” И это уже реальная ачивка, которую не нужно выдумывать.
Почему это важно?
Рынок IT в России перегрет, и быть просто хорошим уже не прокатит. Компании ужесточили подход к найму и бюджету: проекты и зарплаты замораживаются, и если ты не показываешь реальную ценность, можешь легко оказаться в списке сокращений. В такой период важно показывать измеримые результаты и свою эффективность. Но как и любой кризис — это отличный момент, чтобы расти, развиваться и опережать «залетных».
Работать нужно не 8 часов, а головой — особенно сейчас.
❤10
Как собрать итоги работы для повышения
Собрать итоги работы бывает сложнее, чем саму работу работать. В Performance Review оцениваются достижения, и с этим боль почти всегда.
Вот топ-5 лайфхаков, чтобы ваши achievements залетели:
1. Пишите про успехи, а не про задачи. Никто не впечатлится “делал свою работу”. Не “тестировал”, а “уменьшил количество багов”.
2. Добавьте метрики. Оцените, насколько вы “молодец”, в цифрах.
3. Краткость рулит. Как и в резюме: больше не значит лучше, без поэм.
4. Привяжите к командным целям. Важно, как ваши успехи повлияли на общие результаты.
5. Покажите, чему научились. Полгода прошли, вы выросли — расскажите, как это помогло в проекте.
Всем по ляму в секунду, пирожочки, не киснем.
Собрать итоги работы бывает сложнее, чем саму работу работать. В Performance Review оцениваются достижения, и с этим боль почти всегда.
Вот топ-5 лайфхаков, чтобы ваши achievements залетели:
1. Пишите про успехи, а не про задачи. Никто не впечатлится “делал свою работу”. Не “тестировал”, а “уменьшил количество багов”.
2. Добавьте метрики. Оцените, насколько вы “молодец”, в цифрах.
3. Краткость рулит. Как и в резюме: больше не значит лучше, без поэм.
4. Привяжите к командным целям. Важно, как ваши успехи повлияли на общие результаты.
5. Покажите, чему научились. Полгода прошли, вы выросли — расскажите, как это помогло в проекте.
“Человек стоит столько, насколько он способен себя оценить” — Франсуа Рабле.
Всем по ляму в секунду, пирожочки, не киснем.
❤11
Узнавайте куда идет ваша компания
Сидишь, работаешь, за окном уже снег вовсю, а тут твой лид заявляет: «Вася, мы завтра летим в космос, а ты не космонавт, так что, сорян, остаешься на земле». Вопрос «какого, собственно, х… я остаюсь и зачем нам космос?» уже риторический — и задавать его поздно.
У меня не было ни одного проекта или компании, где я бы не сталкивался с моментом, когда внезапно меняется курс, приоритеты или целая команда. Причем по ощущениям всегда ровно в тот момент, когда, кажется, всё наконец-то стабильно. Порой казалось, что все CЕО и директора — просто школьники с биполяркой, которые не могут определиться, чего хотят. Но со временем пришло осознание: с 90% вероятностью план на изменения был, просто я о нем не знал.
Если вы не помогаете стратегии, вы за бортом.
На ранних стадиях у компании нет стратегии, есть гипотеза. Она проверяется, и если компания успешно минует стадию «выжить бы», появляется план на год и больше. Вот в этот момент и начинают писать про «вырасти в 10 раз», «полететь в космос» и «не брать с собой Васю».
Если не хотите, чтобы космические идеи вашего продакта и СЕО застали вас врасплох, начните с того, чтобы спросить своего лида: «Какая у нас IT-стратегия на год?» Если её нет — печально. Если есть — ищите, как вы ей помогаете, или в космос могут полететь без вас.
В любой ситуации — стройте свою стратегию
Вне зависимости от наличия планов в вашей айтишке на то, как она помогает бизнесу, делайте свою локальную стратегию в рамках подразделения. Узнавайте у продактов и ваших ЛПР, что хочет компания на год вперёд, и ищите рычаги, как своей работой на это повлиять.
Основные блоки айти стратегии:
- Цели и задачи
- Команда и её развитие
- Техстек и инструменты
- Процессы и автоматизация
- Метрики, как вы измеряете успех
Своя стратегия — это ваша связь с бизнесом. Чем она прочнее, тем безопаснее и выгоднее для вас. В текущих реалиях рынка — это база.
Сидишь, работаешь, за окном уже снег вовсю, а тут твой лид заявляет: «Вася, мы завтра летим в космос, а ты не космонавт, так что, сорян, остаешься на земле». Вопрос «какого, собственно, х… я остаюсь и зачем нам космос?» уже риторический — и задавать его поздно.
У меня не было ни одного проекта или компании, где я бы не сталкивался с моментом, когда внезапно меняется курс, приоритеты или целая команда. Причем по ощущениям всегда ровно в тот момент, когда, кажется, всё наконец-то стабильно. Порой казалось, что все CЕО и директора — просто школьники с биполяркой, которые не могут определиться, чего хотят. Но со временем пришло осознание: с 90% вероятностью план на изменения был, просто я о нем не знал.
Если вы не помогаете стратегии, вы за бортом.
На ранних стадиях у компании нет стратегии, есть гипотеза. Она проверяется, и если компания успешно минует стадию «выжить бы», появляется план на год и больше. Вот в этот момент и начинают писать про «вырасти в 10 раз», «полететь в космос» и «не брать с собой Васю».
Если не хотите, чтобы космические идеи вашего продакта и СЕО застали вас врасплох, начните с того, чтобы спросить своего лида: «Какая у нас IT-стратегия на год?» Если её нет — печально. Если есть — ищите, как вы ей помогаете, или в космос могут полететь без вас.
В любой ситуации — стройте свою стратегию
Вне зависимости от наличия планов в вашей айтишке на то, как она помогает бизнесу, делайте свою локальную стратегию в рамках подразделения. Узнавайте у продактов и ваших ЛПР, что хочет компания на год вперёд, и ищите рычаги, как своей работой на это повлиять.
Основные блоки айти стратегии:
- Цели и задачи
- Команда и её развитие
- Техстек и инструменты
- Процессы и автоматизация
- Метрики, как вы измеряете успех
Своя стратегия — это ваша связь с бизнесом. Чем она прочнее, тем безопаснее и выгоднее для вас. В текущих реалиях рынка — это база.
❤13
Не будь в коконе
Когда-то я работал в онлайн-аукционе для б/у тачек. Мне довелось общаться с одним из фаундеров из списка Forbes, который регулярно выезжал на аукционы и лично осматривал машины, чтобы понять, как оптимизировать процессы. После планёрки с топами в костюмах, обсуждая ярды, он засучивал рукава и шёл фоткать VIN-номер старой гнилой Газели на морозе.
Но ты не такой. Ты сидишь дома на диване, хомячишь чай с булкой, а реальные проблемы людей для тебя — просто баги в джире. «Саша, тикетов в саппорте за q3 стало больше на 7%». А в этот момент оценщик на морозе, с 3G, загружает минутное 4K-видео работы двигателя в твоё идеально протестированное и pixel-perfect приложение.
Реальность на аукционе выглядела иначе: грязь, холод, нескончаемый поток машин и их владельцы, севшие на ухо оценщику про их «ласточку» — которая лучше всех. На месте я понял: то, что работает в дашборде, часто ломается в реальности. Много тестов пришлось переделывать — менять сценарии, добавлять проверки, сокращать шаги. Только когда мы реально разобрались, как пользователи работают с приложением в условиях аукциона и поменяли подход к тестированию, обращения в саппорте пошли на спад.
Этот опыт научил меня, что строить стратегию качества и разрабатывать автотесты, не понимая реальных условий работы приложения, — значит работать в коконе. Хочешь создать что-то действительно полезное? Побудь реальным пользователем своего сервиса. Нюхни реальность — и стратегия заработает.
Когда-то я работал в онлайн-аукционе для б/у тачек. Мне довелось общаться с одним из фаундеров из списка Forbes, который регулярно выезжал на аукционы и лично осматривал машины, чтобы понять, как оптимизировать процессы. После планёрки с топами в костюмах, обсуждая ярды, он засучивал рукава и шёл фоткать VIN-номер старой гнилой Газели на морозе.
Но ты не такой. Ты сидишь дома на диване, хомячишь чай с булкой, а реальные проблемы людей для тебя — просто баги в джире. «Саша, тикетов в саппорте за q3 стало больше на 7%». А в этот момент оценщик на морозе, с 3G, загружает минутное 4K-видео работы двигателя в твоё идеально протестированное и pixel-perfect приложение.
Реальность на аукционе выглядела иначе: грязь, холод, нескончаемый поток машин и их владельцы, севшие на ухо оценщику про их «ласточку» — которая лучше всех. На месте я понял: то, что работает в дашборде, часто ломается в реальности. Много тестов пришлось переделывать — менять сценарии, добавлять проверки, сокращать шаги. Только когда мы реально разобрались, как пользователи работают с приложением в условиях аукциона и поменяли подход к тестированию, обращения в саппорте пошли на спад.
Этот опыт научил меня, что строить стратегию качества и разрабатывать автотесты, не понимая реальных условий работы приложения, — значит работать в коконе. Хочешь создать что-то действительно полезное? Побудь реальным пользователем своего сервиса. Нюхни реальность — и стратегия заработает.
❤10
Что должно быть в стратегии 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.
Рынок меняется быстрее, чем ты правишь тесты. До конца года всем зрелым ребятам предстоит ежегодное упражнение — формирование стратегии 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.
❤9
Не бойся ломать прод.
Почти каждому QA знакомо чувство, когда он положил прод. Если ещё нет — у тебя всё впередиособенно в пятницу. Интересное зачастую начинается после: начальники начинает разнос в общих чатах, кидают срочные зум колы с единственной целью — найти и наказать. И, конечно, того крайнего в процессе — тестировщика, ведь это он должен был все все протестить, а в итоге уронил. Если бывал в таких в таких компаниях - сочувствую. Если видишь такое в своей компании — беги.
Страх — яд для команды
Как только в вашей компании появляетя страх наказания или увольнения за «сервисные» действия по примеру неудачного релиза, вы начинаете работать сильно хуже. Даже исследования есть: страх резко снижает когнитивные функции. Как результат все бояться и тупят.
Ответственность за релиз — на всей команде
Релиз — это результат работы всей команды и Тимлида. Вы вместе пилите фичу, вместе её тестите и катите. И никто никогда не хочет намеренно что-то сломать. Так что отвечать за результат должны все — от разработчиков до тимлида, а не один тестировщик (как много где принято).
Дух пиратства — лучший настрой для команды
Команда не должна бояться катить релизы. Напрочь это должно будоражить и подталкивать - только с таким настроем запускаются растут проекты. Конечно, уровень «пиратства» может варьироваться - не везде можно катнуть в пятницу и без тестов. Главное — создать атмосферу, где люди не боятся брать на себя ответственность, ведь страх убивает инициативу.
И помните
Всем пятницы и хороших релизов ребятки ❤️
Почти каждому QA знакомо чувство, когда он положил прод. Если ещё нет — у тебя всё впереди
Страх — яд для команды
Как только в вашей компании появляетя страх наказания или увольнения за «сервисные» действия по примеру неудачного релиза, вы начинаете работать сильно хуже. Даже исследования есть: страх резко снижает когнитивные функции. Как результат все бояться и тупят.
Ответственность за релиз — на всей команде
Релиз — это результат работы всей команды и Тимлида. Вы вместе пилите фичу, вместе её тестите и катите. И никто никогда не хочет намеренно что-то сломать. Так что отвечать за результат должны все — от разработчиков до тимлида, а не один тестировщик (как много где принято).
Дух пиратства — лучший настрой для команды
Команда не должна бояться катить релизы. Напрочь это должно будоражить и подталкивать - только с таким настроем запускаются растут проекты. Конечно, уровень «пиратства» может варьироваться - не везде можно катнуть в пятницу и без тестов. Главное — создать атмосферу, где люди не боятся брать на себя ответственность, ведь страх убивает инициативу.
И помните
Быстро откатанное — упавшим не считается
Всем пятницы и хороших релизов ребятки ❤️
❤12
Как стать лучше 99% QA на рынке
За сотни собеседований, которые провел я видел много классных ребят, но слабых QA. Большинство их проблем, что их фокус на инструментах и задачах, а не на цели сделать лучше. Они пишут фреймворки, находят ошибки, формируют отчёты, но от крутых ребят ждут куда больше. Когда ты называешь себя QA - ты должен быть гарантом, что продукт качественный на каждом его этапе. Ты не исполняешь инструкции, а предотвращаяешь проблемы на всем цикле разработки от Discovery до Delivery.
Я выделаю 3 основные вещи, которые должен знать QA, чтобы стать крутым:
1. Ты не ищешь баги — ты делаешь так, чтобы их не было. Вникай в требования и задавай вопросы на этапе обсуждения. Предлагай тест-кейсы ещё до начала написания кода. Концентрируйся на устранении причин ошибок, а не только на их выявлении.
2. Ты автоматизируешь свою работу, а не тесты. Сфокусируйся на автоматизации рутинны: регресса, метрик, отчетов. Оптимизируй свои процессы, чтобы больше времени уделять качеству архитектуры и работы с пользователями. QA измеряется не количеством автотестов, а скоростью с которой поставляются новые (качественные) релизы.
3. Ты — лучший друг Продакта. Вместе с Продактом анализируйте риски, обсуждайте компромиссы. Поддерживай баланс между качеством и сроками, помогая бизнесу зарабатывать. Работай так, чтобы стать для Продакта союзником, а для бизнеса — важным активом.
Если сейчас ты подумал: «на кой мне это? я просто тесты пишу», — окей, пиши дальше и скоро придёт кто-то, кто делает всё это, и тебя заменят. Если же ты подумал: «Ну да, я и так это знал», — круто, ты на правильном пути. Только вот одно дело знать, другое — делать. Делай всегда.
Если хочешь стать действительно QA, а не Тестировщиком — начни использовать эти советы.
За сотни собеседований, которые провел я видел много классных ребят, но слабых QA. Большинство их проблем, что их фокус на инструментах и задачах, а не на цели сделать лучше. Они пишут фреймворки, находят ошибки, формируют отчёты, но от крутых ребят ждут куда больше. Когда ты называешь себя QA - ты должен быть гарантом, что продукт качественный на каждом его этапе. Ты не исполняешь инструкции, а предотвращаяешь проблемы на всем цикле разработки от Discovery до Delivery.
Я выделаю 3 основные вещи, которые должен знать QA, чтобы стать крутым:
1. Ты не ищешь баги — ты делаешь так, чтобы их не было. Вникай в требования и задавай вопросы на этапе обсуждения. Предлагай тест-кейсы ещё до начала написания кода. Концентрируйся на устранении причин ошибок, а не только на их выявлении.
2. Ты автоматизируешь свою работу, а не тесты. Сфокусируйся на автоматизации рутинны: регресса, метрик, отчетов. Оптимизируй свои процессы, чтобы больше времени уделять качеству архитектуры и работы с пользователями. QA измеряется не количеством автотестов, а скоростью с которой поставляются новые (качественные) релизы.
3. Ты — лучший друг Продакта. Вместе с Продактом анализируйте риски, обсуждайте компромиссы. Поддерживай баланс между качеством и сроками, помогая бизнесу зарабатывать. Работай так, чтобы стать для Продакта союзником, а для бизнеса — важным активом.
Если сейчас ты подумал: «на кой мне это? я просто тесты пишу», — окей, пиши дальше и скоро придёт кто-то, кто делает всё это, и тебя заменят. Если же ты подумал: «Ну да, я и так это знал», — круто, ты на правильном пути. Только вот одно дело знать, другое — делать. Делай всегда.
Если хочешь стать действительно QA, а не Тестировщиком — начни использовать эти советы.
❤15
Плюшкины в тестировании
Думаю каждый из нас читал Мертвые души и знаком с Плюшкиным. В куашке таких полно - тех, кто хранитель древних тестов, возрастом с компанию. Держатся за них “а вдруг пригодятся”, даже если никто никогда не откроет их после написания. Это превращаются в священный “черный ящик”, который держит “того самого Васю”. Потом Вася уходит, приходит Вова, выбрасывает всё и автоматизирует заново.
Почему это проблема? Потому что тесты, как и хлам у Плюшкина, не решают задач, а захламляют ваш Allure. План “писать тесты на всё” или “автоматизируем все баги” — это утопия, которая осталась в 2010-х. QA — это не про перепись продукта, а про минимизацию рисков.
Меня часто спрашивают: “Что делать с хламом в тестах и самими Плюшкиными? Как разрулить?” С удовольствием расскажу.
1. Если Плюшкин - ваш руководитель. Печальные новости: если он настаивает, чтобы вы собирали хлам вместе с ним, вы вряд ли что-то докажете. Объяснять бесполезно, менять его подход — ещё сложнее. Мой совет? Не трать время. Ищи место, где ценят качество, а не количество.
2. Если Плюшкин — твой коллега, это сложнее. Работать с хламом никому не хочется, но ты можешь помочь: предложи настроить нормальную модель хранения — разбить их на смоки, регрессы, приёмочные, чтобы избавиться от хаоса, или покажи на своём примере, как делать меньше, но лучше. Если это не сработает, иди к руководителю — хлам одного QA не должен тянуть вниз всю команду.
3. Если ты руководитель Плюшкина - помоги ему провести уборку. Задавай правильные вопросы: “Какой набор тестов нужен для этой фичи?” или “Что проверяет этот тест?”. Если ответа нет — отправляй всё в архив или на удаление. Тесты — это инструмент, а не музейная коллекция. Генерирует хлам дальше? Увольняй.
4. Если Плюшкин - это ты, поздравляю. Наслаждайся своей коллекцией. Генерируй по тыще тестов в спринт, никогда их не прогоняй и гордись, что в твоём царстве никто, кроме тебя, не может разобраться. Пусть коллеги ценят твои сакральные знания.
Думаю каждый из нас читал Мертвые души и знаком с Плюшкиным. В куашке таких полно - тех, кто хранитель древних тестов, возрастом с компанию. Держатся за них “а вдруг пригодятся”, даже если никто никогда не откроет их после написания. Это превращаются в священный “черный ящик”, который держит “того самого Васю”. Потом Вася уходит, приходит Вова, выбрасывает всё и автоматизирует заново.
Почему это проблема? Потому что тесты, как и хлам у Плюшкина, не решают задач, а захламляют ваш Allure. План “писать тесты на всё” или “автоматизируем все баги” — это утопия, которая осталась в 2010-х. QA — это не про перепись продукта, а про минимизацию рисков.
Меня часто спрашивают: “Что делать с хламом в тестах и самими Плюшкиными? Как разрулить?” С удовольствием расскажу.
1. Если Плюшкин - ваш руководитель. Печальные новости: если он настаивает, чтобы вы собирали хлам вместе с ним, вы вряд ли что-то докажете. Объяснять бесполезно, менять его подход — ещё сложнее. Мой совет? Не трать время. Ищи место, где ценят качество, а не количество.
2. Если Плюшкин — твой коллега, это сложнее. Работать с хламом никому не хочется, но ты можешь помочь: предложи настроить нормальную модель хранения — разбить их на смоки, регрессы, приёмочные, чтобы избавиться от хаоса, или покажи на своём примере, как делать меньше, но лучше. Если это не сработает, иди к руководителю — хлам одного QA не должен тянуть вниз всю команду.
3. Если ты руководитель Плюшкина - помоги ему провести уборку. Задавай правильные вопросы: “Какой набор тестов нужен для этой фичи?” или “Что проверяет этот тест?”. Если ответа нет — отправляй всё в архив или на удаление. Тесты — это инструмент, а не музейная коллекция. Генерирует хлам дальше? Увольняй.
4. Если Плюшкин - это ты, поздравляю. Наслаждайся своей коллекцией. Генерируй по тыще тестов в спринт, никогда их не прогоняй и гордись, что в твоём царстве никто, кроме тебя, не может разобраться. Пусть коллеги ценят твои сакральные знания.
❤12
Супергерои только в фильмах
Мне не раз встречались незаменимые Васи, которые занимались всем кроме своей работы. Вася тебе и тестировщик, и архитектор, и продакт, и дизайнер, и просто душа компании. Если у команды проблемы, он будет впервых рядах: всё проверяет, за всех думает, подстраховывает. В команде где есть такой Вася всё начинает крутиться вокруг него. Он закрывает дыры, берёт на себя кучу задач, спасает релизы.
Что происходит с такой командой?
1. Команда похожа на беспомощных детей. Никто не принимает решений, все бегают к Вася.
2. В тестах срач. Хлам вместо структуры, автоматизация на нуле, релизы только через ручное тестирование. Разобраться может только Вася.
3. Команда не растет. Вместо процессов — культ Васи, который подменяет систему собой и блокирует рост.
И вот в команду приходит Head Даня. Он хочет сделать нормально: выкинуть хлам, сделать метрики, написать авто-тесты, построить процессы. И сделать так, чтобы работало всё без Васи и даже без Дани. Но Вася, конечно, не одобрит. Он искренне верит, что без него всё рухнет, ведь кто, если не он? Этот хаос, в котором он чувствует себя незаменимым, для него кажется необходимым, а любые изменения — угрозой его статусу супергероя. Ведь если всё станет прозрачно и системно, Васе придётся признать, что команда может работать без него, а ему наконец то заняться своей работой.
Что делать с Васей?
Если у вас в команде Вася, вот план:
1. Покажите Васе, что его подход больше не работает. Скажите, что продукту нужна самостоятельная команда, а его гиперопека тормозит развитие и команды и самого Васи. Сделайте ему свой индвидуальный план развития.
2. Начинайте менять систему без него. Стройте процессы, формируйте метрики, перерабатывайте тесты, внедряйте автоматизацию. Покажите, команде, что она может работать без Васи.
3. Если Вася не меняется — прощайтесь. Да, всем будет грустно. И вы словите немало хейта при этом решении. Но знаете что? Команда быстро забудет и задышит, а продукт начнёт развиваться быстрее.
Вывод
Вася — как старая футболка: уютно, удобно, но давно пора заменить. Да, поначалу команде будет не хватать его советов и шуток. Но уже через пару итераций работать станет легче, а продукт начнёт расти.
А Вася? Он будет скучать и, возможно, где-нибудь напишет, что “Даня всё разрушил”. Только команда уже научилась жить без “супергероя”. И ей теперь намного лучше.
Мне не раз встречались незаменимые Васи, которые занимались всем кроме своей работы. Вася тебе и тестировщик, и архитектор, и продакт, и дизайнер, и просто душа компании. Если у команды проблемы, он будет впервых рядах: всё проверяет, за всех думает, подстраховывает. В команде где есть такой Вася всё начинает крутиться вокруг него. Он закрывает дыры, берёт на себя кучу задач, спасает релизы.
Что происходит с такой командой?
1. Команда похожа на беспомощных детей. Никто не принимает решений, все бегают к Вася.
2. В тестах срач. Хлам вместо структуры, автоматизация на нуле, релизы только через ручное тестирование. Разобраться может только Вася.
3. Команда не растет. Вместо процессов — культ Васи, который подменяет систему собой и блокирует рост.
И вот в команду приходит Head Даня. Он хочет сделать нормально: выкинуть хлам, сделать метрики, написать авто-тесты, построить процессы. И сделать так, чтобы работало всё без Васи и даже без Дани. Но Вася, конечно, не одобрит. Он искренне верит, что без него всё рухнет, ведь кто, если не он? Этот хаос, в котором он чувствует себя незаменимым, для него кажется необходимым, а любые изменения — угрозой его статусу супергероя. Ведь если всё станет прозрачно и системно, Васе придётся признать, что команда может работать без него, а ему наконец то заняться своей работой.
Что делать с Васей?
Если у вас в команде Вася, вот план:
1. Покажите Васе, что его подход больше не работает. Скажите, что продукту нужна самостоятельная команда, а его гиперопека тормозит развитие и команды и самого Васи. Сделайте ему свой индвидуальный план развития.
2. Начинайте менять систему без него. Стройте процессы, формируйте метрики, перерабатывайте тесты, внедряйте автоматизацию. Покажите, команде, что она может работать без Васи.
3. Если Вася не меняется — прощайтесь. Да, всем будет грустно. И вы словите немало хейта при этом решении. Но знаете что? Команда быстро забудет и задышит, а продукт начнёт развиваться быстрее.
Вывод
Вася — как старая футболка: уютно, удобно, но давно пора заменить. Да, поначалу команде будет не хватать его советов и шуток. Но уже через пару итераций работать станет легче, а продукт начнёт расти.
А Вася? Он будет скучать и, возможно, где-нибудь напишет, что “Даня всё разрушил”. Только команда уже научилась жить без “супергероя”. И ей теперь намного лучше.
❤11
Как писать в чат тестировщику, чтобы всех выбесить
Если ты нормальный QA, ты знаешь, что вся команда ждёт именно тебя. Разработчики, менеджеры — все живут в ожидании твоего финального вердикта: “работает или нет?”. Но давай честно: просто сообщать результат скучно. Настоящий мастер QA превращает мессенджеры в инструмент хаоса, где каждый твой месседж становится точкой напряжения. Расскажу, как это делать правильно.
1. Меншены — наше всё. @developer — это слишком просто. Активно пользуйся @here и @everyone, чтобы все знали, что твой баг — это самая важная проблема на планете.
2. Пиши с пассивной агрессией. Вместо скучного “баг воспроизводится” пиши: “Ну, как обычно, не работает”. С лёгкой ноткой разочарования в человечестве — это важно.
3. Кидай скриншоты с тостера. Если ты всё-таки решил прикрепить скриншот, убедись, что это фото монитора под углом, снятое на старый телефон. И не забудь обвести баг пальцем, который закрывает половину экрана.
4. Скидывай логи без комментариев. Не трать время на объяснения. Пусть команда сама разбирается в том, что значат эти 10 000 строк текста. Это их проблема, а не твоя.
5. Никакого контекста. Просто напиши: “кнопка не работает” — и пропади. Пусть они сами разберутся, какая кнопка, где она находится и что вообще происходит.
6. Капс — твой лучший друг. “ВСЁ ЛЕЖИТ!!!!!!!!!!!” — идеальное сообщение. Добавляй побольше восклицательных знаков и побольше слова “СРОЧНО”, чтобы команда почувствовала реальный драматизм ситуации.
7. Заводи баги прямо в чате. Зачем таск-трекеры, если можно просто написать: “это надо чинить” или “сделайте как в ТЗ”? Чёткие инструкции — для слабаков.
8. Разбивай сообщения. Если у тебя есть мысль из 10 слов, отправь каждое слово отдельным сообщением. Это поможет держать команду в тонусе и сделает чат настоящим полем битвы.
Потому что спокойная команда — это скучная команда. Великие продукты рождаются в состоянии лёгкой ярости, а ты — ключевой двигатель этого состояния. QA, который умеет писать в чат так, чтобы всех довести, — незаменимый инструмент в любом проекте. 😉
Если ты нормальный QA, ты знаешь, что вся команда ждёт именно тебя. Разработчики, менеджеры — все живут в ожидании твоего финального вердикта: “работает или нет?”. Но давай честно: просто сообщать результат скучно. Настоящий мастер QA превращает мессенджеры в инструмент хаоса, где каждый твой месседж становится точкой напряжения. Расскажу, как это делать правильно.
1. Меншены — наше всё. @developer — это слишком просто. Активно пользуйся @here и @everyone, чтобы все знали, что твой баг — это самая важная проблема на планете.
2. Пиши с пассивной агрессией. Вместо скучного “баг воспроизводится” пиши: “Ну, как обычно, не работает”. С лёгкой ноткой разочарования в человечестве — это важно.
3. Кидай скриншоты с тостера. Если ты всё-таки решил прикрепить скриншот, убедись, что это фото монитора под углом, снятое на старый телефон. И не забудь обвести баг пальцем, который закрывает половину экрана.
4. Скидывай логи без комментариев. Не трать время на объяснения. Пусть команда сама разбирается в том, что значат эти 10 000 строк текста. Это их проблема, а не твоя.
5. Никакого контекста. Просто напиши: “кнопка не работает” — и пропади. Пусть они сами разберутся, какая кнопка, где она находится и что вообще происходит.
6. Капс — твой лучший друг. “ВСЁ ЛЕЖИТ!!!!!!!!!!!” — идеальное сообщение. Добавляй побольше восклицательных знаков и побольше слова “СРОЧНО”, чтобы команда почувствовала реальный драматизм ситуации.
7. Заводи баги прямо в чате. Зачем таск-трекеры, если можно просто написать: “это надо чинить” или “сделайте как в ТЗ”? Чёткие инструкции — для слабаков.
8. Разбивай сообщения. Если у тебя есть мысль из 10 слов, отправь каждое слово отдельным сообщением. Это поможет держать команду в тонусе и сделает чат настоящим полем битвы.
Потому что спокойная команда — это скучная команда. Великие продукты рождаются в состоянии лёгкой ярости, а ты — ключевой двигатель этого состояния. QA, который умеет писать в чат так, чтобы всех довести, — незаменимый инструмент в любом проекте. 😉
❤16
Я на встрече самый глупый
«Я не понимаю весь код, который пишут разработчики, вдруг они подумают, что я дурачек.»
«Кажется, мне просто повезло, когда прошел интервью. Рано или поздно все поймут, что я тут случайно.»
«Как вообще тестировать архитектуру, если я даже не знаю, где она хорошая или плохая?»
Давай начнем с хорошей новости: ты не один. Синдром самозванца знаком почти каждому QA (и вообще профессионалу). И вот еще одна хорошая новость: ты можешь с этим справиться, и я знаю, как.
1. Сомневаешься? Это хорошо. Если у тебя есть синдром самозванца, это значит, что ты осознаешь пробелы в своих знаниях. Это не слабость — это сила. Знание своих слабых сторон открывает дверь к росту. Признай это и составь четкий план: что ты хочешь узнать? Каких навыков тебе не хватает?
2. Ты не обязан быть идеальным. Ты не машина, которая знает всё и сразу. Нормально не разбираться во всех архитектурах или фреймворках автоестов. Не знаешь что-то? Найди эксперта, который знает.
3. Ошибаться — это нормально. Да, ты можешь пропустить баг. Да, твой тест может упасть. Ошибки — это не провал, это часть процесса. Даже у Маска ракеты падают, у тебя тоже есть на это право.
Заключение
Когда я прихожу в новую компанию, особенно если это новая для меня сфера, я всегда кайфую от момента, что я на встрече самый глупый. Ты вроде весь такой на опыте и скилах, но в этой области ты профан. И это лучший способ нарабатывать насмотренность и опыт. Для компании же ты глоток нового для них опыта и знаний, которых у них нет. win-win.
Так что не бойся своих сомнений — это нормально. Именно они делают тебя профессионалом.
У тебя всё получится, дружище. 🚀
«Я не понимаю весь код, который пишут разработчики, вдруг они подумают, что я дурачек.»
«Кажется, мне просто повезло, когда прошел интервью. Рано или поздно все поймут, что я тут случайно.»
«Как вообще тестировать архитектуру, если я даже не знаю, где она хорошая или плохая?»
Давай начнем с хорошей новости: ты не один. Синдром самозванца знаком почти каждому QA (и вообще профессионалу). И вот еще одна хорошая новость: ты можешь с этим справиться, и я знаю, как.
1. Сомневаешься? Это хорошо. Если у тебя есть синдром самозванца, это значит, что ты осознаешь пробелы в своих знаниях. Это не слабость — это сила. Знание своих слабых сторон открывает дверь к росту. Признай это и составь четкий план: что ты хочешь узнать? Каких навыков тебе не хватает?
2. Ты не обязан быть идеальным. Ты не машина, которая знает всё и сразу. Нормально не разбираться во всех архитектурах или фреймворках автоестов. Не знаешь что-то? Найди эксперта, который знает.
3. Ошибаться — это нормально. Да, ты можешь пропустить баг. Да, твой тест может упасть. Ошибки — это не провал, это часть процесса. Даже у Маска ракеты падают, у тебя тоже есть на это право.
Заключение
Когда я прихожу в новую компанию, особенно если это новая для меня сфера, я всегда кайфую от момента, что я на встрече самый глупый. Ты вроде весь такой на опыте и скилах, но в этой области ты профан. И это лучший способ нарабатывать насмотренность и опыт. Для компании же ты глоток нового для них опыта и знаний, которых у них нет. win-win.
Так что не бойся своих сомнений — это нормально. Именно они делают тебя профессионалом.
У тебя всё получится, дружище. 🚀
❤21
Forwarded from Король Артур
This media is not supported in your browser
VIEW IN TELEGRAM
Это я готовлюсь толкнуть ахуенную мотивационную речь своим сотрудникам в декабре 2024, вместо тринадцатой зарплаты
😁13
Почему все так любят велосипеды
Давече обсуждали с Артёмом Ерошенко его новую версию Allure 3.0 задавались вопросом: зачем тестировщикам в 2024 году таблички с тестами, если есть инструменты, которые работают лучше? Но, как показывает практика, велосипеды — это не только о тестировании.
Есть много компаний, которые будто бы созданы на фабрике велосипедов. Для каждого процесса — своё уникальное, трёхколёсное и слегка ржавое. Такое ощущение, что их забанили в интернете, а за слово “Scrum” в офисе сжигают на костре.
Вот мой топ-5 самых популярных:
1. Свои инструменты разработки. “Jira? Нам это не подходит, у нас — ‘Реестр задач 2.0’ в Excel. CI/CD? Мы не гугл - у нас FTP.”, “API тестировать не нужно, клиенты его не видят.” В итоге вместо готовых инструментов — своё родное.
2. Уникальные роли. У вас не Project Manager, а “Координатор зон ответственности”. Вместо тестировщика — “Архитектор проверки” и “Менеджер багов”. Звучит красиво, но на деле никто не понимает, кто за что отвечает. Нанять нового сотрудника? Удачи.
3. Свое планирование. “Scrum нам не надо, а Kanban — это вообще для японцев.” Зато у нас есть “динамическая сессия по согласованию задач”. Это когда задачи записываются в “нашу джиру-табличку”, которая обожает терять строки. Приоритеты прыгают каждые два часа, дедлайны — понятие философское.
4. Сопротивление внешнему опыту. “Вы не понимают нашей уникальности.” Конечно, ведь в других местах никто не видит красоту джира-таблички, которая “держит” всю систему. В итоге нанимают людей, готовых учиться внутренней культуре, вместо того чтобы привносить что-то новое.
5. Оргструктура - я художник, я так вижу. “У нас всё идеально: команды разделены, каждый отвечает за своё.” Но любое движение требует трёх менеджеров, трёх встреч и кучи согласований. Простая задача превращается в интереснейший конкурс.
Что из этого выходит?
Это и есть “искажение уникальности” — удобный способ избегать изменений, маскируя хаос под творчество. Роббинс и Джадж в “Организационном поведении” называют это ловушкой, которая приводит к:
1. Сложностям в росте. Новичков невозможно адаптировать, потому что даже опытным людям сложно объяснить это творчество.
2. Зависимость от героев. Всё держится на 2-3 “Васях”. Ушёл Вася — и его велосипед сразу развалился, так как педали крутить некому.
3. Замедлению бизнеса. Вместо работы над продуктом компания бесконечно чинит свой “уникальный” подход.
Если ты думаешь: “У нас всё работает”, — поздравляю, пока что работает. Но как только начнётся масштабирование или кто-то из ключевых уйдёт, всё это превратится в хаос.
Трушная уникальность — это не велосипеды, а умение адаптировать лучшее под себя.
Давече обсуждали с Артёмом Ерошенко его новую версию Allure 3.0 задавались вопросом: зачем тестировщикам в 2024 году таблички с тестами, если есть инструменты, которые работают лучше? Но, как показывает практика, велосипеды — это не только о тестировании.
Есть много компаний, которые будто бы созданы на фабрике велосипедов. Для каждого процесса — своё уникальное, трёхколёсное и слегка ржавое. Такое ощущение, что их забанили в интернете, а за слово “Scrum” в офисе сжигают на костре.
Вот мой топ-5 самых популярных:
1. Свои инструменты разработки. “Jira? Нам это не подходит, у нас — ‘Реестр задач 2.0’ в Excel. CI/CD? Мы не гугл - у нас FTP.”, “API тестировать не нужно, клиенты его не видят.” В итоге вместо готовых инструментов — своё родное.
2. Уникальные роли. У вас не Project Manager, а “Координатор зон ответственности”. Вместо тестировщика — “Архитектор проверки” и “Менеджер багов”. Звучит красиво, но на деле никто не понимает, кто за что отвечает. Нанять нового сотрудника? Удачи.
3. Свое планирование. “Scrum нам не надо, а Kanban — это вообще для японцев.” Зато у нас есть “динамическая сессия по согласованию задач”. Это когда задачи записываются в “нашу джиру-табличку”, которая обожает терять строки. Приоритеты прыгают каждые два часа, дедлайны — понятие философское.
4. Сопротивление внешнему опыту. “Вы не понимают нашей уникальности.” Конечно, ведь в других местах никто не видит красоту джира-таблички, которая “держит” всю систему. В итоге нанимают людей, готовых учиться внутренней культуре, вместо того чтобы привносить что-то новое.
5. Оргструктура - я художник, я так вижу. “У нас всё идеально: команды разделены, каждый отвечает за своё.” Но любое движение требует трёх менеджеров, трёх встреч и кучи согласований. Простая задача превращается в интереснейший конкурс.
Что из этого выходит?
Это и есть “искажение уникальности” — удобный способ избегать изменений, маскируя хаос под творчество. Роббинс и Джадж в “Организационном поведении” называют это ловушкой, которая приводит к:
1. Сложностям в росте. Новичков невозможно адаптировать, потому что даже опытным людям сложно объяснить это творчество.
2. Зависимость от героев. Всё держится на 2-3 “Васях”. Ушёл Вася — и его велосипед сразу развалился, так как педали крутить некому.
3. Замедлению бизнеса. Вместо работы над продуктом компания бесконечно чинит свой “уникальный” подход.
Если ты думаешь: “У нас всё работает”, — поздравляю, пока что работает. Но как только начнётся масштабирование или кто-то из ключевых уйдёт, всё это превратится в хаос.
Трушная уникальность — это не велосипеды, а умение адаптировать лучшее под себя.
❤13
В колхозе больше всех пахала лошадь и ты
Когда я только начинал, мне казалось, что чем больше я работаю, тем ближе успешная жизнь. Работать по 10-12 часов? Конечно, ведь так я стану незаменимым, правда? А потом смотришь на коллегу, который закончил в обед, уехал на новом мерсе, пока ты сидишь до вечера, а домой едешь на метро.
Много работы ≠ много результата
Работать без остановки — это не героизм, а путь в депрессию и покупку купе (клубу 30+ привет). Как говорил Тим Феррис (Как работать по 4 часа в день), эффективность всегда важнее усилий. Ты можешь сделать больше, если сосредоточишься на главном, автоматизируешь рутину, делегируешь задачи и… используешь готовые решения.
Суть херачить — в том, чтобы потом не херачить
1. Автоматизируй рутину. Если ты QA, делай автотесты и пайплайны. Менеджер? Используй трекеры и шаблоны. Каждая минута на автоматизацию сегодня — это часы, которые ты сэкономишь завтра.
2. Фокусируйся на важном. Роберт Шарма (Клуб 5 утра) советовал начинать день с главных задач. 3 выполненные задачи лучше 10 размытых попыток. Работай на результат, а не на «занятость».
3. Делегируй. Ты не супергерой, и это нормально. Делегирование — это не слабость, а умение сосредотачиваться на том, что действительно важно.
4. Запускай быстро. Как писал Руслан, идея, запущенная за 2 недели, даст тебе 80% результата. А стремление к идеалу обычно оставляет проект на этапе «почти готово».
5. Используй готовое. Я уже писал о «велосипедах»: если есть готовое решение, не трать время на изобретение нового. Возьми Trello, а не строй таск-трекер, или бери Allure для отчётов вместо кривой html подделки.
Насмотренность
Если не знаешь, что выбрать, сначала посмотри вокруг. Открой интернет, сходи на конференцию или найди того кто уже делал твою задачу. Мир уже давно придумал большинство решений. Учись смотреть и слушать, иначе все вокруг будут идти вперёд, пока ты с утра до ночи пилишь то что послезавтра выкинешь.
Включай голову
И нет, это не о том, чтобы сидеть на жопе ровно. Это о том, чтобы перестать гнаться за количеством ради количества. Крутой не тот, кто постоянно занят, а тот, кто знает, как не быть занятым. Пусть твоя работа приводит к тому, что через год тебе не придётся делать то, что ты делаешь сейчас. Иначе ты рискуешь быть лошадью, которая больше всех пахала, но в итоге никому не нужна.
Вререди 6 дневная рабочая неделя и долгожданный оливье и отдых. Держимся ребятки ❤️
Когда я только начинал, мне казалось, что чем больше я работаю, тем ближе успешная жизнь. Работать по 10-12 часов? Конечно, ведь так я стану незаменимым, правда? А потом смотришь на коллегу, который закончил в обед, уехал на новом мерсе, пока ты сидишь до вечера, а домой едешь на метро.
Много работы ≠ много результата
Работать без остановки — это не героизм, а путь в депрессию и покупку купе (клубу 30+ привет). Как говорил Тим Феррис (Как работать по 4 часа в день), эффективность всегда важнее усилий. Ты можешь сделать больше, если сосредоточишься на главном, автоматизируешь рутину, делегируешь задачи и… используешь готовые решения.
Суть херачить — в том, чтобы потом не херачить
1. Автоматизируй рутину. Если ты QA, делай автотесты и пайплайны. Менеджер? Используй трекеры и шаблоны. Каждая минута на автоматизацию сегодня — это часы, которые ты сэкономишь завтра.
2. Фокусируйся на важном. Роберт Шарма (Клуб 5 утра) советовал начинать день с главных задач. 3 выполненные задачи лучше 10 размытых попыток. Работай на результат, а не на «занятость».
3. Делегируй. Ты не супергерой, и это нормально. Делегирование — это не слабость, а умение сосредотачиваться на том, что действительно важно.
4. Запускай быстро. Как писал Руслан, идея, запущенная за 2 недели, даст тебе 80% результата. А стремление к идеалу обычно оставляет проект на этапе «почти готово».
5. Используй готовое. Я уже писал о «велосипедах»: если есть готовое решение, не трать время на изобретение нового. Возьми Trello, а не строй таск-трекер, или бери Allure для отчётов вместо кривой html подделки.
Насмотренность
Если не знаешь, что выбрать, сначала посмотри вокруг. Открой интернет, сходи на конференцию или найди того кто уже делал твою задачу. Мир уже давно придумал большинство решений. Учись смотреть и слушать, иначе все вокруг будут идти вперёд, пока ты с утра до ночи пилишь то что послезавтра выкинешь.
Включай голову
И нет, это не о том, чтобы сидеть на жопе ровно. Это о том, чтобы перестать гнаться за количеством ради количества. Крутой не тот, кто постоянно занят, а тот, кто знает, как не быть занятым. Пусть твоя работа приводит к тому, что через год тебе не придётся делать то, что ты делаешь сейчас. Иначе ты рискуешь быть лошадью, которая больше всех пахала, но в итоге никому не нужна.
Вререди 6 дневная рабочая неделя и долгожданный оливье и отдых. Держимся ребятки ❤️
❤17
7 признаков, что ваша команда застряла в 00-х
За годы работы я часто видел команды, которые превратили стабильность в культ, восхваляя процессы и инструменты из 00-х как нечто святое. Любая попытка изменений встречается фразами вроде «У нас так всегда работало» или «Мы не гугл, нам так удобно». Это классический застой, о котором писал Ицхак Адизес: компания достигает стадии «расцвета», но вместо развития цепляется за прошлые успехи, попадая в ловушку ошибки выжившего.
Признаки, что ваш подход пора обновить:
1. Отделы вместо команд. «Разработчики пишут код, QA ищут баги. Всё строго и по полочкам.» В итоге проблемы обнаруживаются на финальных тестах, когда сроки уже горят. Совместная работа? Не слышали.
2. Тяжёлые процессы и Waterfall. «Нужно всё досконально спланировать заранее.» Пока вы согласовываете годовой план, Agile-команды уже выпустили несколько релизов.
3. Автоматизация? Нет, спасибо. «Мы пробовали автоматизировать, всё сломалось, поэтому лучше вручную.» Современные инструменты вроде Cypress и Playwright надёжны и эффективны. Но зачем, если можно продолжать работать дважды дольше?
4. CI/CD — не для нас. «Автоматизированные пайплайны? Это слишком сложно.» Ручные релизы — это как ездить на телеге в эпоху электромобилей. Пока вы вручную запускаете код, конкуренты ускоряют релизы в разы.
5. Монофункциональные роли. «Я тестировщик, и точка. Остальное не моё дело.» Узкие роли тормозят процессы, но зато вам не нужно напрягаться учиться чему-то новому.
6. Массовые планёрки. «Чем больше людей, тем лучше.» Два часа обсуждений, почему кнопка зелёная, а не красная, вместо коротких и продуктивных встреч.
7. Никаких экспериментов. «Мы уже пробовали это, и оно не сработало.» Вчерашние неудачи — это не оправдание стоять на месте. Технологии и контекст меняются.
Вывод:
Стабильность, которой вы так гордитесь, может быть не силой, а слабостью. Если вы узнаёте свою команду в этих признаках, пора пересмотреть подход.
В следующем посте я расскажу о советах, проверенных временем и большими дядями, как из этого выбраться.
За годы работы я часто видел команды, которые превратили стабильность в культ, восхваляя процессы и инструменты из 00-х как нечто святое. Любая попытка изменений встречается фразами вроде «У нас так всегда работало» или «Мы не гугл, нам так удобно». Это классический застой, о котором писал Ицхак Адизес: компания достигает стадии «расцвета», но вместо развития цепляется за прошлые успехи, попадая в ловушку ошибки выжившего.
Признаки, что ваш подход пора обновить:
1. Отделы вместо команд. «Разработчики пишут код, QA ищут баги. Всё строго и по полочкам.» В итоге проблемы обнаруживаются на финальных тестах, когда сроки уже горят. Совместная работа? Не слышали.
2. Тяжёлые процессы и Waterfall. «Нужно всё досконально спланировать заранее.» Пока вы согласовываете годовой план, Agile-команды уже выпустили несколько релизов.
3. Автоматизация? Нет, спасибо. «Мы пробовали автоматизировать, всё сломалось, поэтому лучше вручную.» Современные инструменты вроде Cypress и Playwright надёжны и эффективны. Но зачем, если можно продолжать работать дважды дольше?
4. CI/CD — не для нас. «Автоматизированные пайплайны? Это слишком сложно.» Ручные релизы — это как ездить на телеге в эпоху электромобилей. Пока вы вручную запускаете код, конкуренты ускоряют релизы в разы.
5. Монофункциональные роли. «Я тестировщик, и точка. Остальное не моё дело.» Узкие роли тормозят процессы, но зато вам не нужно напрягаться учиться чему-то новому.
6. Массовые планёрки. «Чем больше людей, тем лучше.» Два часа обсуждений, почему кнопка зелёная, а не красная, вместо коротких и продуктивных встреч.
7. Никаких экспериментов. «Мы уже пробовали это, и оно не сработало.» Вчерашние неудачи — это не оправдание стоять на месте. Технологии и контекст меняются.
Вывод:
Стабильность, которой вы так гордитесь, может быть не силой, а слабостью. Если вы узнаёте свою команду в этих признаках, пора пересмотреть подход.
В следующем посте я расскажу о советах, проверенных временем и большими дядями, как из этого выбраться.
❤8