Плюшкины в тестировании

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

Почему это проблема? Потому что тесты, как и хлам у Плюшкина, не решают задач, а захламляют ваш Allure. План “писать тесты на всё” или “автоматизируем все баги” — это утопия, которая осталась в 2010-х. QA — это не про перепись продукта, а про минимизацию рисков.

Меня часто спрашивают: “Что делать с хламом в тестах и самими Плюшкиными? Как разрулить?” С удовольствием расскажу.

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

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

3. Если ты руководитель Плюшкина - помоги ему провести уборку. Задавай правильные вопросы: “Какой набор тестов нужен для этой фичи?” или “Что проверяет этот тест?”. Если ответа нет — отправляй всё в архив или на удаление. Тесты — это инструмент, а не музейная коллекция. Генерирует хлам дальше? Увольняй.

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

Супергерои только в фильмах

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

Что происходит с такой командой?

1. Команда похожа на беспомощных детей. Никто не принимает решений, все бегают к Вася.
2. В тестах срач. Хлам вместо структуры, автоматизация на нуле, релизы только через ручное тестирование. Разобраться может только Вася.
3. Команда не растет. Вместо процессов — культ Васи, который подменяет систему собой и блокирует рост.

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

Что делать с Васей?

Если у вас в команде Вася, вот план:

1. Покажите Васе, что его подход больше не работает. Скажите, что продукту нужна самостоятельная команда, а его гиперопека тормозит развитие и команды и самого Васи. Сделайте ему свой индвидуальный план развития.
2. Начинайте менять систему без него. Стройте процессы, формируйте метрики, перерабатывайте тесты, внедряйте автоматизацию. Покажите, команде, что она может работать без Васи.
3. Если Вася не меняется — прощайтесь. Да, всем будет грустно. И вы словите немало хейта при этом решении. Но знаете что? Команда быстро забудет и задышит, а продукт начнёт развиваться быстрее.

Вывод

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

А Вася? Он будет скучать и, возможно, где-нибудь напишет, что “Даня всё разрушил”. Только команда уже научилась жить без “супергероя”. И ей теперь намного лучше.

Как писать в чат тестировщику, чтобы всех выбесить

Если ты нормальный QA, ты знаешь, что вся команда ждёт именно тебя. Разработчики, менеджеры — все живут в ожидании твоего финального вердикта: “работает или нет?”. Но давай честно: просто сообщать результат скучно. Настоящий мастер QA превращает мессенджеры в инструмент хаоса, где каждый твой месседж становится точкой напряжения. Расскажу, как это делать правильно.

1. Меншены — наше всё. @developer — это слишком просто. Активно пользуйся @here и @everyone, чтобы все знали, что твой баг — это самая важная проблема на планете.

2. Пиши с пассивной агрессией. Вместо скучного “баг воспроизводится” пиши: “Ну, как обычно, не работает”. С лёгкой ноткой разочарования в человечестве — это важно.

3. Кидай скриншоты с тостера. Если ты всё-таки решил прикрепить скриншот, убедись, что это фото монитора под углом, снятое на старый телефон. И не забудь обвести баг пальцем, который закрывает половину экрана.

4. Скидывай логи без комментариев. Не трать время на объяснения. Пусть команда сама разбирается в том, что значат эти 10 000 строк текста. Это их проблема, а не твоя.

5. Никакого контекста. Просто напиши: “кнопка не работает” — и пропади. Пусть они сами разберутся, какая кнопка, где она находится и что вообще происходит.

6. Капс — твой лучший друг. “ВСЁ ЛЕЖИТ!!!!!!!!!!!” — идеальное сообщение. Добавляй побольше восклицательных знаков и побольше слова “СРОЧНО”, чтобы команда почувствовала реальный драматизм ситуации.

7. Заводи баги прямо в чате. Зачем таск-трекеры, если можно просто написать: “это надо чинить” или “сделайте как в ТЗ”? Чёткие инструкции — для слабаков.

8. Разбивай сообщения. Если у тебя есть мысль из 10 слов, отправь каждое слово отдельным сообщением. Это поможет держать команду в тонусе и сделает чат настоящим полем битвы.

Потому что спокойная команда — это скучная команда. Великие продукты рождаются в состоянии лёгкой ярости, а ты — ключевой двигатель этого состояния. QA, который умеет писать в чат так, чтобы всех довести, — незаменимый инструмент в любом проекте. 😉

Пишите в ChatGPT - «based on you know about me, draw a picture of my life»

У меня получилось вот так - нравится 🙂

Я на встрече самый глупый

«Я не понимаю весь код, который пишут разработчики, вдруг они подумают, что я дурачек.»

«Кажется, мне просто повезло, когда прошел интервью. Рано или поздно все поймут, что я тут случайно.»

«Как вообще тестировать архитектуру, если я даже не знаю, где она хорошая или плохая?»

Давай начнем с хорошей новости: ты не один. Синдром самозванца знаком почти каждому QA (и вообще профессионалу). И вот еще одна хорошая новость: ты можешь с этим справиться, и я знаю, как.

1. Сомневаешься? Это хорошо. Если у тебя есть синдром самозванца, это значит, что ты осознаешь пробелы в своих знаниях. Это не слабость — это сила. Знание своих слабых сторон открывает дверь к росту. Признай это и составь четкий план: что ты хочешь узнать? Каких навыков тебе не хватает?

2. Ты не обязан быть идеальным. Ты не машина, которая знает всё и сразу. Нормально не разбираться во всех архитектурах или фреймворках автоестов. Не знаешь что-то? Найди эксперта, который знает.

3. Ошибаться — это нормально. Да, ты можешь пропустить баг. Да, твой тест может упасть. Ошибки — это не провал, это часть процесса. Даже у Маска ракеты падают, у тебя тоже есть на это право.

Заключение

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

Так что не бойся своих сомнений — это нормально. Именно они делают тебя профессионалом.
У тебя всё получится, дружище. 🚀

Все готовы к новогодним корпоративам?

Это я готовлюсь толкнуть ахуенную мотивационную речь своим сотрудникам в декабре 2024, вместо тринадцатой зарплаты

Почему все так любят велосипеды

Давече обсуждали с Артёмом Ерошенко его новую версию 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. Замедлению бизнеса. Вместо работы над продуктом компания бесконечно чинит свой “уникальный” подход.

Если ты думаешь: “У нас всё работает”, — поздравляю, пока что работает. Но как только начнётся масштабирование или кто-то из ключевых уйдёт, всё это превратится в хаос.

Трушная уникальность — это не велосипеды, а умение адаптировать лучшее под себя.

В колхозе больше всех пахала лошадь и ты

Когда я только начинал, мне казалось, что чем больше я работаю, тем ближе успешная жизнь. Работать по 10-12 часов? Конечно, ведь так я стану незаменимым, правда? А потом смотришь на коллегу, который закончил в обед, уехал на новом мерсе, пока ты сидишь до вечера, а домой едешь на метро.

Много работы ≠ много результата

Работать без остановки — это не героизм, а путь в депрессию и покупку купе (клубу 30+ привет). Как говорил Тим Феррис (Как работать по 4 часа в день), эффективность всегда важнее усилий. Ты можешь сделать больше, если сосредоточишься на главном, автоматизируешь рутину, делегируешь задачи и… используешь готовые решения.

Суть херачить — в том, чтобы потом не херачить

1. Автоматизируй рутину. Если ты QA, делай автотесты и пайплайны. Менеджер? Используй трекеры и шаблоны. Каждая минута на автоматизацию сегодня — это часы, которые ты сэкономишь завтра.
2. Фокусируйся на важном. Роберт Шарма (Клуб 5 утра) советовал начинать день с главных задач. 3 выполненные задачи лучше 10 размытых попыток. Работай на результат, а не на «занятость».
3. Делегируй. Ты не супергерой, и это нормально. Делегирование — это не слабость, а умение сосредотачиваться на том, что действительно важно.
4. Запускай быстро. Как писал Руслан, идея, запущенная за 2 недели, даст тебе 80% результата. А стремление к идеалу обычно оставляет проект на этапе «почти готово».
5. Используй готовое. Я уже писал о «велосипедах»: если есть готовое решение, не трать время на изобретение нового. Возьми Trello, а не строй таск-трекер, или бери Allure для отчётов вместо кривой html подделки.

Насмотренность

Если не знаешь, что выбрать, сначала посмотри вокруг. Открой интернет, сходи на конференцию или найди того кто уже делал твою задачу. Мир уже давно придумал большинство решений. Учись смотреть и слушать, иначе все вокруг будут идти вперёд, пока ты с утра до ночи пилишь то что послезавтра выкинешь.

Включай голову

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

Вререди 6 дневная рабочая неделя и долгожданный оливье и отдых. Держимся ребятки ❤️

7 признаков, что ваша команда застряла в 00-х

За годы работы я часто видел команды, которые превратили стабильность в культ, восхваляя процессы и инструменты из 00-х как нечто святое. Любая попытка изменений встречается фразами вроде «У нас так всегда работало» или «Мы не гугл, нам так удобно». Это классический застой, о котором писал Ицхак Адизес: компания достигает стадии «расцвета», но вместо развития цепляется за прошлые успехи, попадая в ловушку ошибки выжившего.
Признаки, что ваш подход пора обновить:

1. Отделы вместо команд. «Разработчики пишут код, QA ищут баги. Всё строго и по полочкам.» В итоге проблемы обнаруживаются на финальных тестах, когда сроки уже горят. Совместная работа? Не слышали.

2. Тяжёлые процессы и Waterfall. «Нужно всё досконально спланировать заранее.» Пока вы согласовываете годовой план, Agile-команды уже выпустили несколько релизов.

3. Автоматизация? Нет, спасибо. «Мы пробовали автоматизировать, всё сломалось, поэтому лучше вручную.» Современные инструменты вроде Cypress и Playwright надёжны и эффективны. Но зачем, если можно продолжать работать дважды дольше?

4. CI/CD — не для нас. «Автоматизированные пайплайны? Это слишком сложно.» Ручные релизы — это как ездить на телеге в эпоху электромобилей. Пока вы вручную запускаете код, конкуренты ускоряют релизы в разы.

5. Монофункциональные роли. «Я тестировщик, и точка. Остальное не моё дело.» Узкие роли тормозят процессы, но зато вам не нужно напрягаться учиться чему-то новому.

6. Массовые планёрки. «Чем больше людей, тем лучше.» Два часа обсуждений, почему кнопка зелёная, а не красная, вместо коротких и продуктивных встреч.

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

Вывод:

Стабильность, которой вы так гордитесь, может быть не силой, а слабостью. Если вы узнаёте свою команду в этих признаках, пора пересмотреть подход.

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

С наступающим!

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

В 2025 желаю всем лёгких релизов, больших денег и мирного неба. Пусть это будет год смелых экспериментов и крутых результатов. 🚀 🎅🏼🍾

Пиратство или бюрократия?

В 2015 году я пришёл в стартап CarPrice, и первое время просто офигевал. До этого я работал в классической компании с отделами где разработчики пишут код а QA ищут баги, всё строго по полочкам. А тут — продуктовые команды, OKR-ы, кальянная в офисе и в целом пахнет свободой. Моей первой реакцией было: «это хаос, так нельзя» Но чем больше я наблюдал, тем яснее становилось: можно. И нужно.

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

На старте бизнеса отделы помогают: есть порядок, роли понятны. Но чем больше проект, тем очевиднее, что эта структура мешает двигаться вперёд. Вот почему:

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

2. Бюрократия. «Сначала утвердим планы, потом начнём делать.» Пока вы месяцы согласовываете планы, команды выпускают три релиза. То, что работало в 00-х, сейчас откатывает вас туда же.

3. KPI против пользователя. В отчётах всё идеально, каждый отдел отработал свою часть. А пользователь заходит в продукт и думает: «Что это за хрень?» Итог: всем всё пофиг, но метрики сданы.

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

1. Интеграция. Разработчики, QA, аналитики — все работают над одним продуктом, решая проблемы на месте, а не перекладывая их по вашему длиннющему воркфлоу в джире.

2. Фокус на результат. Задачи вроде «протестировать фичу» заменяются целью «сделать фичу, которая увеличит конверсию». Работа на продукт, а не на отчёты.

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

Отделы — это отличный способ навести порядок на старте. Но если компания хочет двигаться вперёд, расти и оставаться конкурентоспособной, это больше не работает. В ВК и Сбере переход к командам дал автономность людям делать пользу, участил деплои и сократил time2market. Мы видели, как идеи превращались в релизы за недели, а не месяцы.

Посмотрите на свою структуру: она двигает вас вперёд или тянет назад?

Как выбесить команду разработки

Быть хорошим лидом – скучно. Поддерживать, вдохновлять, помогать? Нет, это для слабаков. Что, если ты решил пойти против системы и стать лидом, чьё имя вызывает ужас в команде? Если твоя цель – хаос, выгорание и абсолютный контроль? У меня есть пара советов, как сделать это максимально эффективно

1. Будь мастером микроменеджмента. Следи за каждой строчкой кода, комментируй каждое решение команды. Постоянно уточняй, что и как они делают. Если разработчик не прислал статус за 15 минут – пиши ему в личку: “А где мы с этим?”. Никто не должен расслабляться.

2. Устраивай бесконечные встречи. Статусы, стендапы, созвоны, викли, ретро – и так каждый день. Минимум 6 часов встреч в календаре у каждого члена команды. Команда ведь обожают созвоны с тобой.

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

4. Игнорируй обратную связь. Кто-то пытается предложить улучшение процесса? Забудь. Ты знаешь лучше. Либо пропускай предложения мимо ушей, либо ставь их под сомнение фразами вроде: “А зачем нам это?”

5. Внедряй “фичи-сюрпризы”. Зачем команда планирует спринты? Чтобы ты внезапно добавил новую критическую хрень на второй неделе. Так ребята лучше поймут, что в этом мире нет ничего постоянного.

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

Айтишка - маленькая деревня

В 2018 году, когда я был молод и глуп, уходя из стартапа хлопнул дверью, переругавшись с CPO и CTO и ушёл с чувством собственной значимости. Тогда казалось, что это мощный ход — пусть знают, кто тут батя. А потом в других компаниях я раз за разом натыкался на людей, которые работали с ними, учились вместе или просто были знакомы. Спойлер: со временем обиды загладили, общаемся нормально. Но именно тогда я понял: айтишка — это маленькая деревня, где все друг друга знают, даже если ты об этом не в курсе.

Ты можешь менять компании, но связи остаются. Сегодня ты ржешь с разрабом в курилке, а через пару лет он CTO в компании мечты. Сегодня тимлид спорит с тобой на митинге, а завтра он дает о тебе рекомендацию в новую компанию. Ты думаешь, что прошлое осталось позади, но внезапно твой бывший коллега знаком с твоим будущим начальником. А теперь угадай, что он о тебе расскажет? Айтишка - это клуб старых знакомых, которые регулярно пересекаются.

Так что, если хочешь усложнить себе жизнь, вот проверенный метод: уходи с драмой, поливай всех дерьмом, громко заявляй, что “без меня тут всё развалится”. Спойлер: не развалится, а вот репутация твоя — да. Люди запоминают токсичность дольше, чем достижения. Твой гневный пост в линке или колкое сообщение в чате потом могут решить, позовут ли тебя в новую команду.

А если хочешь, чтобы двери сами открывались, работай на своё имя. Если тебя знают как нормального, адекватного и профессионального, вакансии будут находить тебя сами. Люди будут рекомендовать, звать, предлагать крутые проекты. А если хоть раз жахнуть по мосту — потом будешь долго удивляться, почему все дороги куда-то не туда. Так что вопрос простой: каким тебя запомнят, когда ты выйдешь из чата?

Ребята привет.
Пост новостей и найма.

Новость 1 - Я в Делимобиль (будут посты как тут интересно)
Новость 2 - Ищу в команду героев👨🏻‍🎤

QA Lead направления B2C
Senior QA команды Платформы
Senior QA команды Billing

Пишем на Kotlin/Java/Swift. Строим лучшую платформу качества среди каршеринг сервисов 🤌🏽

Писать мне или откликаться тут https://career.delimobil.ru/