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

Как я вкатился в 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 выкатили в Х гайд по лупам для агентов — разбирайтесь, пока не прилетело

Там расписали четыре типа: агентный, целевой, временной (который по расписанию гоняет) и полностью автономные. Еще показали, как чекать результат, выставлять условия для остановки и не сливать токены вхолостую.

Тащи в закладки, если хочешь прокачать агентный код

👉 QA-логия

⁣Почему опытные тестировщики перестают жалеть разработчиков и как это делает их сильнее

Когда я только начинал в QA, я реально жалел разработчиков. «Они же пашут, сроки горят, продукт сложный, а я тут ещё баги нахожу — ну как они всё успевают?» Знакомо, наверное.

Проходит полгода-год. И замечаешь одну и ту же картину: один и тот же разраб раз за разом делает одинаковые ошибки, требования не читает, граничные случаи не проверяет, а потом искренне удивляется багу. Моя жалость сначала превратилась в раздражение. А потом — в холодное понимание: жалость просто убивает качество.

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

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

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

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

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

Если я пропускаю баг из жалости, я делаю хуже и разработчику (ему потом фиксить инцидент), и себе (меня не повышают за пропущенные баги), и продукту. Жёсткость и уважение — не антагонисты.

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

И да, я всё ещё могу пожалеть разработчика, если вижу, что он реально выложился, но система или требования подвели. Но теперь это осознанный выбор, а не привычка.

Жалость — это скрытая форма неуважения к профессионализму коллеги. Когда перестаёшь жалеть, начинаешь требовать. И команда от этого только сильнее.

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

👉 QA-логия

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

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

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

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

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

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

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

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

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