QA-Логия

⁣Вчера на созвоне с лидом обсуждали баг, который я нашёл ещё две недели назад. Критический — падает оплата в мобильном приложении. Но его до сих пор не починили. Почему? Потому что я просто кинул его в трекер с заголовком «Ошибка при оплате через Google Pay». И всё. Разработчик посмотрел, сказал «воспроизвести не смог» и закрыл. А я даже не уточнил, на каком устройстве тестировал, не приложил видео, не указал шаги до авторизации и версию Android. В итоге баг висит уже третью неделю, а менеджеру всё равно — он не понимает, насколько это критично для бизнеса. И меня не повышают, потому что «ты вроде молодец, но баги теряются». А пара месяцев назад коллега нашёл похожий баг — и уже через неделю его пофиксили, а коллегу назначили старшим тестировщиком. В чём разница? Он умеет «продавать» баги. Что значит «продать» баг? Это не про то, чтобы врать или приукрашивать. Это про то, чтобы донести ценность бага до всех участников процесса. Для разработчика: показать чёткие шаги, окружение, логи, скриншоты. Для менеджера: объяснить влияние на пользователя и бизнес. Например: «При оплате Google Pay падает — теряем 15% конверсии на этапе checkout». Для продукт-оунера: указать, какие сценарии блокируются и какой процент пользователей может столкнуться. Типичная ошибка junior-тестировщика — думать, что баг-репорт нужен только разработчику. Нет. Это документ, который продаёт важность проблемы всей команде. Если вы просто кидаете баги, как в чёрный ящик, то быстро становитесь «тем, кто находит кучу мусора». А нужно становиться «тем, кто спасает релиз». Что я изменил в своём подходе? Добавляю контекст бизнеса. В каждом баг-репорте пишу, на какую функциональность влияет и сколько пользователей может задеть. Пример: «Баг ломает сценарий быстрого заказа для 30% новых пользователей». Прикладываю доказательства. Видео, логи, снимки экрана — обязательно. Если баг редкий, пишу частоту воспроизведения (1 из 10 попыток). Прогнозирую последствия: «Если не починить до релиза, в продакшене получим всплеск жалоб в поддержку и потерю дохода». Общаюсь с разработчиком до отправки. Уточняю, что он уже знает, чтобы не дублировать. Спрашиваю, нужна ли дополнительная информация. Результат? Разработчики перестали закрывать мои баги с пометкой «не воспроизводится». Менеджеры начали включать мои баги в список критических задач. А через три месяца меня повысили до middle с расширением зоны ответственности. Находить баги — база. Уметь их продавать — навык, который отделяет junior от middle и выше. Потому что ваша ценность не в количестве найденных дефектов, а в том, как вы помогаете команде приоритизировать и решать проблемы. А вы замечали, что коллеги, которые красиво описывают баги, быстрее растут по карьере? Или у вас другой опыт? Делитесь в комментариях.

Contract testing на Pact в 2026: как перестать латать интеграции после того, как всё упало В статье разбираемся, как Pact закрывает дыру между модульными и E2E‑тестами, как работают consumer‑driven контракты, Pact Broker и команда can‑i‑deploy, и что важно запомнить, чтобы контрактное тестирование реально блокировало несовместимые релизы, а не плодило ещё одну головную боль. Читать далее: https://habr.com/ru/companies/otus/articles/1058382/ 👉 QA-логия

ИИ для QA: готовим критерии приёмки без километровых мучений Йо, народ! Я Марго, QA из команды МС в Банки.ру. Этой весной мы с пацанами запилили автоматизацию написания Acceptance Criteria через AI. Теперь вместо тупой рутины — бах, и тестирование летит быстрее. Все подробности выкатили на Хабре: Тыкай сюда 👉 QA-логия

Кажется, digital снова меняется быстрее, чем мы успеваем это осознать. На днях Amazon Ads встроил кнопку «Добавить в корзину» прямо в пульт от телевизора. Теперь купить товар можно буквально во время просмотра фильма или сериала — без поиска сайта и переходов. Похоже, борьба за внимание закончилась. Началась борьба за одну кнопку. Такие изменения лучше всего показывают, куда движется рынок. И если работаешь в digital или IT, важно замечать не только громкие новости, но и понимать, какие возможности они открывают. Поэтому мы собрали подборку людей, которые не просто следят за новостями, а первыми разбирают, что действительно изменит рынок. Здесь можно почитать подборки, обзоры, реальные кейсы и идеи, которые помогают смотреть на digital и IT немного шире. Сохранить подборку себе 📨

Если хочешь развиваться в машинном обучении — решать реальные бизнес-задачи или уйти в исследования — в Центральном университете есть магистратура под оба сценария. И на нее можно получить грант до 75%. Места ограничены, дедлайн подачи заявок — 20 августа. «Машинное обучение» — это направление с несколькими форматами и треками. В офлайн-формате (пары по вечерам и в выходные в центре Москвы) можно выбрать один из трех треков: ⚫️Индустриальный — сильная база в ML, современные инструменты, реальные задачи от партнеров ⚫️Научный (AIRI × ЦУ) — сложные модели, исследования, подготовка к аспирантуре и работе в передовых лабораториях ⚫️ML в электронной коммерции × Lamoda — работа с реальными данными Lamoda, применение ML для бизнес-задач и возможность попасть на стажировку в компанию Для тех, кто хочет учиться из любой точки мира, есть онлайн-формат: основной трек и продвинутый — для специалистов с опытом в ML. Это полноценная альтернатива офлайну с теми же преподавателями и курсами. Магистратура в Центральном университете — это 2 года обучения, которое можно совмещать с работой, и диплом государственного образца. Карьерная поддержка начинается еще во время учебы: консультации, тренировочные собеседования и помощь с трудоустройством. Студенты уже в процессе обучения выходят на новые позиции или повышаются в грейде в Яндексе, Авито, Т-Банке и других компаниях. Поступление проходит через грантовый конкурс — это одновременно способ попасть на программу и возможность выиграть финансовую поддержку на все время обучения: грант покрывает до 75% стоимости. В 2026 году доступно 550 грантов на все программы магистратуры. Подробнее о программах и условиях участия в конкурсе — по ссылкам ➡️Офлайн программа ➡️Онлайн программа

⁣Как ответить на вопрос «Что ты делаешь, если не можешь воспроизвести баг?» - и показать уровень мышления middle, а не junior Вчера на собеседовании слышу: «Если баг не воспроизводится - пишу подробный баг-репорт и двигаюсь дальше». Звучит как «я сделал, что мог». Но middle так не думает. Junior обычно говорит: пробую ещё раз, пишу баг с тем, что есть, переключаюсь. Middle отвечает иначе. Невоспроизводимый баг - это не тупик, а зона для исследования. Вот что я делаю на самом деле. Сначала собираю контекст до отказа. Точное время, окружение, версию, данные, последовательность. Скриншоты, видео, логи, console errors. Спрашиваю, что делал до этого - мог ли повлиять другой сценарий. Потом лезу в логи и инструменты. Backend, прокси вроде Charles или Fiddler, логи Sentry - там часто видно ошибку. Ищу аномалии по времени. Дальше пробую граничные условия. Данные с спецсимволами, большие объёмы, состояние системы вроде кеша или сессии, порядок операций, старый браузер, медленная сеть. Формулирую гипотезу и тестирую её. Пишу: «вероятно, баг проявляется при условии X». Делаю 10-20 прогонов подряд. Если всё равно тишина - добавляю пассивные проверки. Чекер в автотесты или мониторинг с тегом «flaky» и описанием. Коммуницирую: «Пока не воспроизвёл, но вот гипотеза, логи, скриншоты. Давайте трекать». Типичная ошибка middle - делать вид, что бага нет. Или закрывать задачу без анализа. Так не работает. Коротко: если баг не воспроизводится - я провожу мини-расследование: анализирую окружение, логи, гипотезы. Если всё равно нет - фиксирую условия, коммуницирую с командой и оставляю задачу открытой с тегом intermittent.

QA-Логия: Как я на Cursor'е запилила отчет по дифференциальному тестированию Авторша раскатывает историю, как она сваяла отчет по дифференциальному тестированию — ну там, где две функции гоняют на одних и тех же данных, а ты смотришь, кто облажался. Раньше на такую хрень уходила прорва времени, а теперь тупой AI за пару минут выплевывает готовый отчет. Может, и тебя этот пример подтолкнет сделать что-то похожее и не париться =)) Читать далее 👉 QA-логия

OpenAI с Антропиком раздают халяву тем, кто вайбкодит — и это прекрасно. 🟢 В Codex поснимали лимиты и убрали пятичасовые ограничения для Plus, Business и Pro. Временно, но кайфуем. 🟢 Fable 5 погостит на платных тарифах до 19 июля. А Claude Code подняли лимиты на 50% аж на неделю. Да будет эта битва Альтмана с Амодеей длиться бесконечно 🙏 👉 QA-логия

⁣Как не слить статус middle в первой же неделе на новом проекте: правила входа в команду для тех, кто хочет расти дальше Ты прошёл собеседование, тебя взяли middle. Поздравляю. Но самое сложное - не дойти до оффера, а не потерять статус в первую же неделю на проекте. Я видел десятки случаев, когда крепкий middle приходил в новую команду и через месяц начинал выглядеть как переросший junior. Почему? Не потому что плохо тестировал. А потому что неправильно вошёл. Вот несколько правил, которые помогут не слить репутацию, а наоборот - закрепить статус и продолжить рост. Правило 1. Не пытайся всех впечатлить в первый день Самая частая ошибка - рваться "спасать проект". Ты хочешь показать, что пришёл профессионал. Но без контекста ты не видишь нюансов: почему баги в проде, почему тесты не покрывают всё, почему команда молчит. Вместо героизма - задавай вопросы. "Почему здесь так?", "Какие риски вы уже знаете?". Middle-мышление - это не "я всё исправлю", а "я сначала пойму". Правило 2. Найди своего "проводника" В каждой команде есть человек, который знает всё: от legacy-костылей до негласных правил. Найди его в первую неделю. Спроси: "Какие три самые опасные зоны в продукте?", "Где теряется время?". Не стесняйся. Middle должен уметь встраиваться в социальную структуру, а не только в код. Правило 3. Не критикуй вслух то, что не видел в работе Ты можешь заметить, что тест-кейсы устарели, документация хромает, баги не воспроизводятся. Сначала проверь гипотезу. Потом спроси: "А это точно так?" И только потом предлагай изменения. Если ты с порога скажешь "у вас тут всё не так" - станешь врагом, а не коллегой. Статус middle держится на дипломатии и фактах. Правило 4. Покажи, что ты умеешь приоритизировать Новый проект - поток информации. Ты не сможешь выучить всё за неделю. Определи: что критично для твоей первой задачи? Флоу главного сценария? Логи багов? Среда? Выбери 3 ключевых фокуса и сделай их глубоко. Легче показать одно качественное исследование, чем пять поверхностных. Правило 5. Задавай "умные" вопросы, а не "детские" Middle-уровень - это не стеснение. Но вопрос "А что это за кнопка?" лучше заменить на "Я вижу этот функционал, но не понял его зависимость от соседнего модуля. Можем разобрать его вместе?". Ты показываешь, что видишь систему, а не экран. Типичная ошибка Вспомни случай: пришёл middle на проект, на второй день нашёл баг в продакшене, побежал к менеджеру с криком "всё плохо". Оказалось, это было известное ограничение, которое команда документировала. Впечатление - сорвано. Уважение - потеряно. Статус - под вопросом. Первая неделя - это не про тесты. Это про контекст, доверие и стратегию. Если ты потратишь её на изучение, а не на доказательства, через месяц тебя воспримут как взрослого специалиста. И тогда статус middle станет не просто званием, а реальным уровнем. Этот подход я проверял на себе и на коллегах. Работает.

⁣Почему ты ушёл с прошлого места? Вопрос, на котором можно запросто потерять оффер. Сижу на собеседовании, всё норм. Потом эйчар спрашивает: «А почему вы ушли?». Ну я и выдал честно — токсичная атмосфера, менеджмент не слышит, микроменеджмент. Вроде правда. Оффер не прилетел. Потом знакомый из той компании сказал: «Ты звучал как человек, который будет жаловаться на любого нового тимлида». И я понял, в чём прокол. Интервьюеру плевать на вашу правду. Ему важно — притащите ли вы эту же драму к нему в команду. Как отвечать, если на прошлой работе реально было болото? Первое. Слово «токсичный» не произносите. Для эйчара это красный флаг: «конфликтный кандидат». Работает формула: «перестал совпадать по подходам». Второе. Смещайте фокус на себя. Лучший ответ: «Я упёрся в потолок. Новые задачи не появлялись. Хочу расти в направлении Х и решать задачи уровня Y». Третье. Если уволили — не врите. Скажите прямо: «Попал под реструктуризацию, команду расформировали. Разошлись хорошо, есть рекомендации». Четвёртое. Критикуйте не людей, а систему. Вместо «начальник был дурак» — «Было много хаоса в приоритетах, задачи меняли каждый день, не хватало структуры». Частая ошибка джунов — рассказывать драму. Собеседование не психотерапия. Чем суше ответ, тем выше шанс. Мой шаблон для QA работает стабильно: «На предыдущем месте я реализовал задачи: выстроил регресс, наладил коммуникацию с разработкой. Дальше рост упёрся в отсутствие сложных интеграционных проектов. Хочу работать с большей неопределённостью и развиваться в нагрузочном тестировании. Поэтому я здесь». Продавайте будущее, не объясняйте прошлое. Говорите, что хотите делать, а не от чего бежите. Тогда оффер ваш.

Слушай, если твой пайплайн тормозит, это почти никогда не из-за одной гигантской проблемы. Чаще всего драгоценные минуты просто незаметно сжирает мелочь: сдохший кэш, жирные образы, тупые очереди и циклические зависимости между джобами. Всё это по капле высасывает время, пока ты не замечаешь. Давай разберем шесть классических идиотских ошибок при настройке GitLab Runner. И главное — как самому найти это узкое место, пока твоя команда не смирилась с двадцатиминутными сборками и не начала ставить чайник при старте. Читать далее Habr 👉 QA-логия

⁣Как отвечать на вопрос «Какие книги по тестированию вы читали?» и не потерять баллы на собеседовании даже без списка литературы Вопрос «Какие книги по тестированию вы читали?» - ловушка. Не потому что интервьюер хочет проверить начитанность, а потому что проверяет твоё отношение к профессии. Я сам провалился на этом. Сказал честно: «Ни одной не прочитал, всё изучал на практике». Потерял баллы. Понял почему: интервьюеру нужен был не список, а сигнал о системном подходе к росту. В чём суть вопроса? На собеседовании (middle и выше) это проверка: интересуешься ли профессией вне работы, способен ли структурировать знания, умеешь ли учиться у опыта других. Как отвечать, если книг не читал? Худшее: сказать «нет» и замолчать. Лучшее: честно признать и объяснить, как учишься иначе. Шаблон ответа: - честность - «Книг от корки до корки не прочитал, это моя зона роста, но я компенсирую это другими способами» - альтернативы - «Читаю статьи и доклады на Хабре или YouTube по конкретным проблемам. Например, при внедрении API-тестов изучил кейсы коллег. Прохожу курсы с домашкой - это даёт структуру» - конкретика - «Из книг открывал «Как тестируют в Google» и «Путь к изучению тестирования» по ситуациям. Планирую изучить «Тестирование ДОТКОМ» Криспина для agile-контекста» - рефрейминг - «Для тестировщика важнее умение задавать вопросы и критическое мышление. При тесте нового функционала я сначала разбираюсь в бизнес-логике, а не в техниках из книги» Почему работает? Показываешь осознанность: не читал, но знаешь о книгах. Даёшь равноценную замену: практика, статьи, курсы. Уходишь от обороны в диалог. Типичная ошибка - врать. Опытный интервьюер легко прощупает: спросит детали, и ты поплывёшь. Лучше честно признать пробел и показать его осознание. Совет: прочитай хотя бы одну прикладную книгу. Например, «Тестирование программного обеспечения» Савина. Не целиком, главу про техники тест-дизайна, чтобы привести живой пример. Книги не самоцель. Цель - системное мышление и желание расти. Если книг нет, покажи, как растёшь иначе. Честность плюс аргументация дают контроль над мячом. А вы сталкивались с таким вопросом? Как отвечали?

Как я вкатился в Bug Bounty в 2026-м: чему меня выучил Black Box-анализ веб-морды одного IT-гиганта Поделюсь ламповой историей про собственный опыт в багбаунти в 2026 году. В чем суть: как я влез в эту движуху, какой урок вынес из Black Box-анализа веб-приложения крупной конторы и что в итоге получилось. 👉 QA-логия

Вырастил своего агента, так сказать, получилось 🥲 👉 QA-логия

OpenAI выкатывает GPT-5.6 Sol, Terra и Luna — уже завтра! Кое-кто уже получил ранний доступ по всему миру, так что погнали чекать. Вот это я понимаю — утро удалось Подробнее: x.com/openai/status/2074704958419792299?s=46 👉 QA-логия

Anthropic выкатили в Х гайд по лупам для агентов — разбирайтесь, пока не прилетело 😨 Там расписали четыре типа: агентный, целевой, временной (который по расписанию гоняет) и полностью автономные. Еще показали, как чекать результат, выставлять условия для остановки и не сливать токены вхолостую. Тащи в закладки, если хочешь прокачать агентный код (https://x.com/ClaudeDevs/status/2074208949205881033) 😎 👉 QA-логия

⁣Почему опытные тестировщики перестают жалеть разработчиков и как это делает их сильнее Когда я только начинал в QA, я реально жалел разработчиков. «Они же пашут, сроки горят, продукт сложный, а я тут ещё баги нахожу — ну как они всё успевают?» Знакомо, наверное. Проходит полгода-год. И замечаешь одну и ту же картину: один и тот же разраб раз за разом делает одинаковые ошибки, требования не читает, граничные случаи не проверяет, а потом искренне удивляется багу. Моя жалость сначала превратилась в раздражение. А потом — в холодное понимание: жалость просто убивает качество. Вот что происходит, когда перестаёшь жалеть разработчиков и начинаешь относиться к ним как к равным профессионалам. Первое. Уходит синдром спасателя. Раньше я мог промолчать, если видел, что задача недоделана, но дедлайн уже завтра. «Ну, старался человек, пусть потом патчем поправит». И что? Баг уходит в прод, мы получаем инцидент, страдает репутация QA. Когда я перестал жалеть, я начал говорить прямо: «Вот ошибка. Исправляй сейчас, иначе не приму». Разработчик злится? Бывает. Но продакшн становится стабильнее. Второе. Развивается профессиональная жёсткость. Жалость — это эмоция. А QA — про факты. Когда жалеешь, начинаешь придумывать оправдания за другого. Опытный тестировщик вместо этого анализирует: «Почему баг вообще появился? Что в процессе пошло не так?» Так разговор переходит из плоскости «кто виноват» в «как исправить процесс». И вот тут ты становишься сильнее — ты не просто ищешь баги, а строишь систему, которая их предотвращает. Третье. Перестаёшь бояться конфликтов. Многие джуны боятся обидеть разработчика — пишут баг-репорты в стиле «возможно, тут есть небольшая неточность». Опытный QA пишет: «Ожидаемое: А. Фактическое: Б. Приоритет — Critical». Без эмоций и извинений. И если разработчик начинает ныть: «Это не баг, это фича», ты спокойно открываешь требования и показываешь разницу. Жалость уходит, уважение приходит.

Типичная ошибка: путать профессионализм с грубостью. Перестать жалеть — не значит стать мудаком. Это значит уважать чужое и своё время.

Если я пропускаю баг из жалости, я делаю хуже и разработчику (ему потом фиксить инцидент), и себе (меня не повышают за пропущенные баги), и продукту. Жёсткость и уважение — не антагонисты. Как это делает тебя сильнее. Ты перестаёшь быть мальчиком или девочкой для битья — тебя начинают слушать. Ты учишься отстаивать свою экспертную позицию, а это ключевой навык для middle и senior. Ты начинаешь видеть системные проблемы, а не только единичные баги. И перестаёшь выгорать от чувства вины за «лишние» баги. И да, я всё ещё могу пожалеть разработчика, если вижу, что он реально выложился, но система или требования подвели. Но теперь это осознанный выбор, а не привычка. Жалость — это скрытая форма неуважения к профессионализму коллеги. Когда перестаёшь жалеть, начинаешь требовать. И команда от этого только сильнее.

Пристегнись, спойлеры уже на подходе 🥲 👉 QA-логия

⁣Как перестать спорить с разработчиками и не тратить нервы на пустые обсуждения багов Каждый тестировщик через это проходил. Описываешь баг: скриншоты, логи, чёткие шаги. А в ответ: "у меня работает" или "это логика приложения". Я часто вижу такие ситуации, и грань между нормальной обратной связью и пустыми отговорками тут тонкая, но важная. Разработчики тоже люди и защищают свою работу. Но для QA ключевой навык — не просто найти баг, а донести его так, чтобы захотелось чинить. По опыту, полезное обсуждение заканчивается там, где начинаются споры ради споров. Конструктивная обратная связь — это когда разработчик даёт конкретику. Например: "Это известное поведение, в трекере есть баг — вот ссылка". Или: "Не чиним сейчас, потому что в следующем спринте переписываем модуль". Или: "Я проверил, ошибка из-за стороннего сервиса. Давай вместе посмотрим логи". Такая реакция двигает процесс вперёд. Неконструктивная — это бездоказательные отписки. Меня всегда настораживает: "У меня работает" без уточнения среды или версии. Или "Это не требует исправления" без объяснения причин. Или "Ты не проверял, это по спецификации" — хотя спецификации нет или она противоречит себе. А ещё "Сделай лучше сценарий, я не могу воспроизвести" — если шаги точны, это его головная боль, не ваша. Как избежать пустых споров. Первое — проверяю себя: баг действительно воспроизводим, описан без субъективщины? Если уверен — стою на своём. Второе — захожу со стороны данных: "Я проверил на трёх окружениях, в логах ошибка X. Давай покажу на созвоне за 5 минут". Третье — не принимаю на свой счёт. Фраза "у меня работает" — не про то, что я плохой тестировщик. Моя задача мягко, но настойчиво потребовать предметный ответ. Четвёртое — если спор в тупике, зову аналитика или техлида. У меня есть золотая практика: после третьего возражения говорю: "Ок, давай я напишу баг с низким приоритетом и объясню, почему это влияет на пользователя. Если считаешь, что неважно — отклони с комментарием". 9 из 10 разработчиков либо разбираются, либо открывают задачу. Почему? Потому что запись в трекере — публичный след, и они не хотят оставлять его без аргументов. Конструктивный диалог всегда ведёт к действию или документированию. Неконструктивный — эмоции и пустота. Требуйте либо фикс, либо чёткое обоснование. Тогда нервы целы, а продукт не страдает.

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

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