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

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

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

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

Конструктивная обратная связь — это когда разработчик даёт конкретику. Например: "Это известное поведение, в трекере есть баг — вот ссылка". Или: "Не чиним сейчас, потому что в следующем спринте переписываем модуль". Или: "Я проверил, ошибка из-за стороннего сервиса. Давай вместе посмотрим логи". Такая реакция двигает процесс вперёд.

Неконструктивная — это бездоказательные отписки. Меня всегда настораживает: "У меня работает" без уточнения среды или версии. Или "Это не требует исправления" без объяснения причин. Или "Ты не проверял, это по спецификации" — хотя спецификации нет или она противоречит себе. А ещё "Сделай лучше сценарий, я не могу воспроизвести" — если шаги точны, это его головная боль, не ваша.

Как избежать пустых споров. Первое — проверяю себя: баг действительно воспроизводим, описан без субъективщины? Если уверен — стою на своём. Второе — захожу со стороны данных: "Я проверил на трёх окружениях, в логах ошибка X. Давай покажу на созвоне за 5 минут". Третье — не принимаю на свой счёт. Фраза "у меня работает" — не про то, что я плохой тестировщик. Моя задача мягко, но настойчиво потребовать предметный ответ. Четвёртое — если спор в тупике, зову аналитика или техлида.

У меня есть золотая практика: после третьего возражения говорю: "Ок, давай я напишу баг с низким приоритетом и объясню, почему это влияет на пользователя. Если считаешь, что неважно — отклони с комментарием". 9 из 10 разработчиков либо разбираются, либо открывают задачу. Почему? Потому что запись в трекере — публичный след, и они не хотят оставлять его без аргументов.

Конструктивный диалог всегда ведёт к действию или документированию. Неконструктивный — эмоции и пустота. Требуйте либо фикс, либо чёткое обоснование. Тогда нервы целы, а продукт не страдает.

Делитесь в комментариях, как вы выходили из таких споров.

Как отказ бизнесу спас 10 миллионов рублей

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

Близился конец проекта, мы уже практически завершили внедрение нового биллинга. Бюджет был распределен, а команды готовились к запуску. И в этот момент бизнес пришел с новым требованием: «Давайте еще перенесем архивные продукты и исторические данные по ним». Архивные продукты использовались редко, но время от времени сотрудники обращались к ним для разбора спорных ситуаций. Мы вместе с архитекторами и аналитиками оценили объем работ. Оказалось, что типового механизма нет, нужно менять архитектуру. Разрабатывать новые сценарии миграции, тестировать, поддерживать. Когда сложили оценки, получилось около 10 миллионов рублей. После пересчета финансовой модели стало понятно, что дополнительные инвестиции сильно увеличивают срок окупаемости проекта на один год. Проще говоря, компания вкладывала деньги в функциональность, которая не приносила измеримой бизнес-ценности.

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

Читать далее

⁣Сидеть и работать в корпорации страшно, жизнь-то мимо проходит. Уходить строить бизнес страшно, а вдруг прогорит. Один из вариантов - разрабатывать свой пет-проект по вечерам. Многие успешные компании, например, Twitter, создавались именно так. Это не значит, что ваш проект обязательно заработает миллиарды, но заработать больше, чем в найме, и получить ценный опыт вполне реально.

Перед началом разработки появляется множество вопросов, например:

– Как выбрать идею для пет-проекта?
– Что нужно знать про маркетинг?
– Как запуститься и довести до первых продаж не имея бюджета на рекламу?

В телеграм-канале Твой пет проект, Михаил Табунов делится своим опытом с разработчиками и менеджерами.

Он рассказывает, где искать идею для нового проекта, что нужно знать о маркетинге, как запустить стартап и привлечь первых 10 клиентов, а также о многих других важных вещах.

Подписывайтесь на Твой пет проект получайте пользу от практиков рынка!

Почему корсет не вышел на сцену: вторая часть истории о докладе «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.

Читать далее