Телеграм канал «QA-Логия»

Почему корсет не вышел на сцену: вторая часть истории о докладе «PROvoke» на Analyst Days

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

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

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

Читать на Хабре

⁣Почему твой ответ на вопрос «Что ты будешь делать, если баг не воспроизводится?» стоит тебе оффера: как перестать давать шаблонные решения и показать зрелость мышления

Вчера на созвоне с коллегой разбирали кейс: кандидат на мидла провалил собеседование на ровном месте. Вопрос классический: «Что будешь делать, если баг не воспроизводится?». Казалось бы, база. Но ответ стоил ему оффера.

Почему? Он выдал шаблон: «Перезалью билд, проверю на другой среде, добавлю логи». Технически верно, но поверхностно. Интервьюер ждал не список действий, а мышление.

Главная ошибка — давать чек-лист. Ты звучишь как исполнитель. Сеньор или лид слышит: «Нет системного подхода, не умеет анализировать корень». Баг, который не воспроизводится — это информационная неопределенность. Твоя задача — снять её, а не бегать с логами.

Как выглядит зрелый ответ.

Сначала я пойму, где искать. Проанализирую: баг стабильный или плавающий? Зависит от данных, времени, состояния системы? Какие шаги пользователя я упускаю? Задаю вопросы, а не прыгаю в дебаг.

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

Затем воспроизведу гипотезу. Строю гипотезу о причине и сознательно её проверяю. Если не сработала — строю новую.

И главное: фиксирую, что не удалось воспроизвести, и согласовываю с командой — нужен ли дополнительный анализ. Это про управление рисками.

Реальный пример. Был баг: «При оплате картой падает приложение» — не воспроизводится на тестовых стендах. Младший QA перебирал окружения. Я спросил: «Какие именно карты?». Оказалось, баг только на картах одного региона. Посмотрели логи — разница в формате номера. Решили за час.

Что запомнить: не давайте алгоритм действий, покажите ход мыслей. Говорите о гипотезах и снятии неопределенности. Подчеркните, что работаете в связке с командой и думаете о пользователе. Ответьте логикой, а не списком — результат удивит.

⁣Как не принимать баги на веру: практика «сомнительного дефекта» и проверка гипотезы за 5 минут

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

Практика «сомнительного дефекта» — это техника, которая помогает не тратить время команды на проверку очевидных ошибок. Она простая, но требует дисциплины.

Суть: когда видишь поведение, которое кажется неправильным, остановись и задай себе 3 вопроса за 5 минут.

1. Могу ли я воспроизвести это стабильно? Если баг появляется раз в 10 попыток — это уже повод насторожиться. Если один раз из десяти — возможно, я что-то сделал не так.
2. Соответствует ли поведение требованиям? Я открываю документацию, ТЗ или спецификацию. Часто оказывается, что «баг» — это описанное поведение, которое я просто не заметил.
3. Есть ли логи или доказательства? Если я не могу снять скриншот, записать видео или собрать логи — бага нет. Разработчик просто закроет его с пометкой «не воспроизводится».

Самая типичная ошибка — путать баг с особенностью работы среды. Например, на staging-сервере кеш сбрасывается раз в 5 минут, а я решил, что данные пропадают. Или баг на локальной машине из-за кривой конфигурации Docker.

Как проверить гипотезу за 5 минут:
- Попробуй другой браузер или устройство.
- Сбрось кеш и куки.
- Сравни поведение на staging и production.
- Спроси коллегу: «А у тебя такое было?» Иногда достаточно двух пар глаз.

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

Сомнительный дефект — не баг. Научись отличать предположение от факта. Тогда твои баг-репорты станут золотым стандартом, а ты — ценным специалистом.

Как я написал ИИ-агента для автооткликов на HH.ru и сэкономил кучу времени

Я расскажу, как написал собственного автономного ИИ-агента для поиска работы на HH.ru. Основная проблема сейчас — рынок IT беспощаден к новичкам: нужно откликаться на сотни вакансий, но большинство откликов просто игнорируются или получают отказы от роботов. Чтобы пробиться через фильтры HR, под каждую вакансию нужно писать уникальное сопроводительное письмо, что отнимает массу времени.

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

Читать далее

⁣Замечаю у коллег всё чаще такую стратегию: застрял в росте - меняй проект. Разработка новая, доменная область свежая, авось и новые скиллы сами подтянутся. И так каждый год. Только вот, по моим наблюдениям, это всё чаще путь не вверх, а по кругу.

Смена проекта - это отличный способ снять "бампер" комфорта, посмотреть другие процессы, попробовать другой стек, познакомиться с новой бизнес-логикой. Но она не делает из джуна мидла, а из мидла сеньора. В чём подвох?

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

Junior -> Middle. Джуну не хватает системности, ответственности за качество в широком смысле и умения видеть риски на несколько шагов вперёд. Переход на новый проект даёт лишь опыт в разных чек-листах и баг-трекинговых системах. Но это количество, а не качество. Чтобы вырасти в мидла, нужно научиться отвечать на вопросы: "Почему я тестирую именно это?", "Какие нефункциональные риски я упускаю?", "Как мой чек-лист связан с архитектурой приложения?". Новая предметная область не научит рефлексии над собственными подходами.

Middle -> Senior. Мидл уже умеет тестировать сложные фичи. Чтобы стать сеньором, нужно: тащить ответственность за весь процесс, строить коммуникацию, влиять на решения команды и видеть продукт целиком. Смена проекта даёт новые контексты, но если на каждом прошлом проекте ты оставался "золотым исполнителем", а не драйвером изменений, то на новом месте ты снова будешь строить регресс и писать баги. Сеньор растёт там, где он остаётся достаточно долго, чтобы увидеть цикл полного развития и влияния.

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

Практический вывод. Если чувствуешь, что упёрся в потолок, не пили резюме в первую очередь. Остановись. Спроси себя: "Какую именно новую компетенцию я хочу развить?" Если это про системный взгляд - перестань бегать. Начни брать на себя больше ответственности на текущем месте: участвуй в уточнении требований, предлагай метрики качества. Если это про управленческие навыки - стань ментором для новичка на проекте. Смена проекта станет ускорителем, когда уже есть база, а не заменителем развития. А вы как думаете? Что чаще становится триггером к смене работы?

⁣«Почему ушёл с прошлого места?» — вопрос, который валит даже уверенных middle'ов. Рассказываю, как отвечать без потери лица и позиции.

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

Плохие ответы — красные флаги:
* «Там был ужасный менеджмент, ничего не работало».
* «Коллеги некомпетентные, тесты писать не умели».
* «Платили мало, а требовали много».
Такие ответы говорят не о проблемах проекта, а о вас: «Я конфликтный», «Я не умею договариваться», «Я обвиняю других».

Как отвечать правильно: 3 рабочих приёма от реальных собеседований.

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

Второй — фокус на новых задачах для горизонтального роста. Пример: «Мне стало интересно попробовать себя в performance/security или автотесты на API, а на проекте таких задач не было. Я решил целенаправленно искать проект, где это смогу делать профессионально».

Третий — объективные факторы. Работает, если причина реальна: релокация или смена стека. Пример: «Проект перешёл на другую технологию — с Java на C#, и моя экспертиза в Python стала невостребованна. Мы договорились расстаться по соглашению сторон, чтобы я мог развиваться в том, что мне интересно».

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

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

Попробуйте сейчас: напишите свой вариант ответа в комментарии — я скажу, прокатит или нет.

⁣Как я перестал писать длинные чек-листы и начал учить разработчиков самопроверке

Раньше я считал, что идеальный чек-лист - это подробный документ на 200 пунктов. Я тратил часы на расписывание каждого шага: "нажать кнопку", "проверить цвет", "убедиться, что текст не съехал". Разработчики смотрели на это и либо игнорировали, либо пробегали по диагонали. А потом - баги, конфликты, фразы вроде "это не моя зона ответственности".

Однажды я понял: длинные чек-листы не учат разработчика думать. Они учат механически выполнять команды. И вместо контроля качества получается имитация.

Я перестроил подход. Теперь перед сдачей фичи я даю разработчику не список проверок, а три вопроса.

Что именно ты изменил? - требует осознания кода. Какие сценарии могут сломаться? - развивает критическое мышление. Как ты это проверил? - вынуждает показать доказательства: скриншоты, логи, тесты.

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

Что делать, если внедрить такой подход сложно? Начинайте с малого: предложите для одной фичи вместо чек-листа провести мозговой штурм. Покажите выгоду: меньше переделок - быстрее доставка. Не давите: если разработчик упорно просит чек-лист, дайте короткий (10-15 пунктов) и постепенно сокращайте.

Главная ошибка новичков: копировать мои вопросы дословно, не адаптируя под команду. Например, если разработчики не пишут юнит-тесты, вопрос "как ты это проверил" вызовет раздражение. Адаптируйте: "Покажи, что код работает в браузере".

Почему это круто для карьеры: Переход от "контролера" к "наставнику" повышает ваш авторитет. Разработчики начинают уважать вас как эксперта, а не как надзирателя. Вы освобождаете время для сложных кейсов: нагрузки, безопасности, UX-анализа.

Недостатки метода (честно): Нужна хорошая коммуникация. Если команда не готова к диалогу, сначала настройте контакт. Медленнее на старте: первые фичи могут потребовать больше обсуждений, чем проверка по чек-листу. Не подходит для регрессионных блоков, где нужно быстро убедиться, что ничего не сломалось.

Как я пришел к этому выводу: Я проработал 5 лет на проекте, где каждый релиз сопровождался 50-страничным чек-листом. Разработчики сдавали баги, тестировщики находили новые, сроки горели. Когда я предложил сократить чек-листы, мой лид сказал: "так исторически сложилось". Я ослушался - и через месяц команда сама попросила не возвращаться к старому подходу.

Совет для роста: начните с малого - замените чек-лист на 3 вопроса для одной фичи. Через месяц сравните количество багов от разработчиков и время на тестирование. Увидите разницу.

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