Телеграм канал «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 разработчиков либо разбираются, либо открывают задачу. Почему? Потому что запись в трекере — публичный след, и они не хотят оставлять его без аргументов.

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

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

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

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

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

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

Читать далее