Одиннадцать недель я вёл дневник каждой рабочей сессии с Claude Code: часы агента, свои часы, судьба каждого кандидата в дефекты. Вышло 277 агентских часов против 213 моих и 94 подтверждённые находки — 77 нашёл агент, 16 я. Внутри: почём обошёлся час агента, где он не окупился, что пропустил и почему первый подсчёт находок оказался завышен почти вдвое.
Тесты — это способ общения с системой: через них она рассказывает своему автору, что у неё болит. Чтобы общение было лёгким, тесты должны запускаться быстро. В идеале должна быть возможность задать вопрос системе о состоянии конкретного участка, и получить моментальный ответ.
Но практика показывает, что наладить такое общение может оказаться на удивление нетривиальной задачей. Чем мощнее становится инфраструктура, тем больше становится тестов, и время полноценного запуска по-прежнему измеряется часами. А код растёт и изменяется всё быстрее из-за ИИ, поэтому проверять приходится всё чаще.
В той или иной форме механизм точечных перезапусков в тестовых фреймворках обычно есть. Но сделать так, чтобы этот механизм гладко работал в CI — задача гораздо более сложная.
В этой статье я запущу тестовую сюиту на стеке JUnit + Gradle + GitHub Actions, и опробую различные способы перезапуска конкретных тестов в ней.
Привет, Хабр! Меня зовут Михаил Новотарский, в Сбере я руковожу внедрением ИИ-практик в трайбе внутренних продуктов Workspace примерно на тысячу человек, а ещё развиваю профессиональное сообщество тестировщиков.
За карьеру я успел побыть почти во всех ролях, которые есть в QA: ручное тестирование, автоматизация, full stack и менеджмент. Поэтому мне особенно интересно наблюдать, как меняется сама профессия, и хочется обсудить, изменится ли её роль в будущем. Чтобы поговорить об этом предметно, введём персонажа — QA-киберагента. Это тестировщик, который не боится нового, постоянно развивает свои навыки и пытается понять, что будет дальше.
В статье разберем, как через LFR-уязвимость во внешнем сервисе облачной инфраструктуры удалось полностью скомпрометировать облако.
Точкой входа стал вспомогательный калькулятор расчета тарифов, в котором нашлась возможность чтения произвольных локальных файлов. Из одной этой уязвимости выросла цепочка, которая в итоге привела к доступу к панели управления облаком под учетной записью с полными правами.
Компания EvaTeam представила обновление ИТ-конвейера разработки полного цикла EvaDev до версии 2.33 «Воронеж». В новой версии EvaProject можно тиражировать уже настроенные доски между проектами, без помощи администратора импортировать задачи из CSV, подключать к задачам данные напрямую из PostgreSQL, MS SQL, MySQL и Oracle. В EvaGant улучшены быстрые трансформации задач на графике, гибкие группировки, смена видов представления. В EvaTest стало возможным группировать тест-кейсы в планах и прогонах и переносить тестовую библиотеку из Zephyr вместе со структурой и историей прогонов. В EvaWiki появились Центр шаблонов, SQL- и BPMN-плагины, а в EvaServiceDesk — новые возможности для форм, согласований и сбора обратной связи.
Разбираем главные изменения нового релиза экосистемы EvaDev 2.33 «Воронеж».
У меня в проде работает ИИ-консультант на сайте. У него есть два правила, которые нарушать нельзя вообще: не называть цены и не называть клиентов, которые под NDA. Оба правила были написаны в системном промпте капслоком, с объяснением почему.
Я замерил, как они соблюдаются. Получилось так:
В своей же справке я нашёл фразу, которая была неправдой. Не устарела - была неправдой с самого начала. Дальше про то, как сделать так, чтобы кодовая база физически не могла врать в документации, и почему главная сложность тут не в тестах, а в списке исключений.
ИИ уже умеет генерировать тесты, разбирать легаси-код и помогать с автоматизацией QA. Но без правил и контроля он так же уверенно создает бесполезные проверки. Поэтому главный вопрос сегодня — не «можно ли применять ИИ в тестировании», а «как встроить его в процесс, чтобы качество действительно росло».
Модераторы INFOSTART TECH EVENT 2026 обсудили, где ИИ уже помогает тестировщикам, зачем растущим командам матрицы компетенций и почему качество продукта давно перестало быть зоной ответственности только QA.
Недавно читал тут статью про «Cost per Task» и про то, что самая дешёвая модель в линейке внезапно обгоняет самую умную по цене решённой задачи. С выводом согласен полностью, но хочу добавить то, чего в той статье не было: дело не только в модели. Дело в том, что происходит после того, как модель написала код.
Последние восемь месяцев я строю агентную обвязку, в которой модель не просто пишет файлы, а обязана доказать, что написанное работает. Выяснилось следующее: если прикрутить к слабой модели честный цикл верификации, она уверенно обходит сильную модель, работающую в режиме «написал и отчитался».
Ниже цифры, архитектура и грабли.
Есть один, уже набивший оскомину спор, по популярности уступающий, пожалуй, только извечному спору Iphone vs Android. Это спор сможет ли вайбкодер с ИИ заменить программистов старой школы.
Все в итоге плюс минус сходятся во мнении, что вайбкодеры «с нуля» не смогут. Опытный программист с ИИ — это как грузчик с экзоскелетом — может гораздо больше унести. А вот опытный вайбкодер, собаку съевший на особенностях работы с ИИ? Он не знает ЯП двадцать лет. Зато рядом с ним сидит машина, которая умеет генерировать код, читать документацию, анализировать репозиторий, писать тесты, искать ошибки и выполнять десятки итераций за время, за которое человек успевает открыть документацию и сделать задумчивое лицо.
Поэтому родилась такая мысль: а кто сегодня быстрее и качественнее решит реальную инженерную задачу? Не — кто лучше пишет код. Не — кто умнее. Не — кто красивее оформляет GitHub. А кто за ограниченное время выдаст лучший работающий результат. Предлагаю устроить эксперимент.
На этой неделе на Хабре спорили, нужны ли программисту самые умные модели или для рутины хватит дешёвых. Триста комментариев и ни одного замера на одинаковых задачах. Я сделал: пять рутинных задач, четыре модели одного семейства, по два прогона, скрытые тесты. Сорок прогонов.
Самая дорогая модель оказалась самой быстрой: 341 секунда против 395 у самой дешёвой, потому что ей нужно меньше ходов и вдвое меньше текста. Четыре задачи из пяти решили все, 32 прогона из 32. А на пятой младшая модель написала баг и отчиталась двумя галочками подряд, вторая из которых опровергает первую.
Агент завершил запуск, вернул корректный формат и прошёл автоматическую проверку. Почему этого всё ещё недостаточно для приёмки — и какие отдельные гейты нужны между completion и решением человека.
SQL‑инъекция через декомпиляцию: от JAR‑файла до захвата пароля
Материал носит образовательный характер. Все работы велись легально, в рамках пентеста, с письменного согласия владельца системы и в изолированном контуре. Название клиента и продукта не раскрываем — NDA. Имена классов, пакетов и таблиц в листингах изменены. Применяйте это только на системах, доступ к которым у вас есть. Доступ к чужим системам без разрешения преследуется по закону.
Корпоративная Java‑система: складской учет, веб‑интерфейс, HTTPS. Внутри — SQL‑инъекция без аутентификации в одном GET‑запросе, из‑за строки «... WHERE ID=» + параметр.
Разберем, как найти такую в приложении без исходников: декомпиляция JAR → чтение сервлетов → уязвимая строка → подтверждение через pg_sleep. Каждый шаг воспроизводим.
Почти каждый тестировщик на перфоманс-ревью хоть раз ловил либо чувство недооценённости, либо налёт синдрома самозванца, когда кажется, что тебя переоценили. На самом деле чаще всего это отражение не вас и ваших скиллов, а состояние системы оценки, в которой вы находитесь.
Меня зовут Миша Соколов, я старший специалист по тестированию в Контуре. Расскажу, как у нас трансформировалась система оценки QA-инженеров. Спойлер: это был путь от плоской Excel-таблички со скиллами из актуальных вакансий на рынке до разветвлённой структуры из пяти треков развития и распределённого матричного управления для 270+ QA-инженеров.
Flaky‑тесты становятся проблемой задолго до того, как их количество начинает измеряться сотнями. Один нестабильный тест способен скрыть реальный баг, замедлить CI и заставить команду тратить время на повторные прогоны. В статье разберём, почему привычные решения вроде ретраев и sleep() часто маскируют проблему, как искать скрытые источники нестабильности и какие подходы помогают сделать автотесты предсказуемее.
Осторожность кажется полезной настройкой для ИИ-агента. Но три прогона на 100 реальных багах из SWE-bench дали обратный результат: «правила дисциплины» по мотивам советов Карпати снизили число исправлений примерно на 13%. Разберём результаты эксперимента и посмотрим, в какой момент разумные ограничения превращаются для агента в тормоза.
Привет, Хабр!
Меня зовут Кирилл Кайданов, я старший инженер-программист в компании «Гарда». Я несколько лет занимался исключительно багами, достаточно редко брал какие-либо другие задачки. И так получилось, что в целом эта сфера по-прежнему осталась любимой частью работы.
Представьте археолога на раскопках. Он не начинает хаотично перебирать все найденные предметы в надежде сразу обнаружить ценную находку. Сперва он изучает местность, формирует гипотезы, постепенно сужая таким образом область поиска. Каждый найденный фрагмент помогает ему понять, где искать дальше, а каждая неподтвердившаяся гипотеза — исключить очередное заблуждение.
С поиском причин багов примерно та же история. Их легко превратить в хаотичные попытки переписывания кода. Но отладка — это системный инженерный процесс, основанный на дедукции. Здесь нет места игре в угадайку. Важно сформировать гипотезы и последовательно отсекать те области, где проблем гарантированно нет.
Под катом делюсь мануалом, который помогает мне быстрее вычислять баги. Хотя основная часть моей практики связана с C++, но предлагаемый в статье подход универсален и не зависит от языка программирования или стека. Гарантирую, что он будет работать даже в ситуации, когда нужно разбираться с системой на незнакомом языке.
В первом приложении мне было легко понять, чем заняться дальше. Всегда находилась ещё одна функция, которую можно добавить: новый экран, аналитика, AI, оплата. Каждая закрытая задача давала понятное ощущение прогресса. Продукт становился больше, код — сложнее, релизы — заметнее.
После большого релиза я задал себе неприятный вопрос: что именно я доказал? Что могу довести приложение до работающего состояния — да. Что людям нужна каждая из реализованных функций и они готовы возвращаться — уже не факт.
Со вторым проектом я решил поменять порядок работы. Не начинать с большого roadmap и каталога возможностей, а сначала сформулировать одно повторяемое действие, которое можно проверить. Так появился Prosnix — Telegram Mini App для личных экспериментов после пробуждения.
Это не история успешного запуска. Пользователей пилота и подтверждённых результатов пока нет. Это история о том, как попытка сделать более узкий MVP изменила мои технические решения — и почему даже одна простая продуктовая метрика потребовала state machine, нескольких версий и отдельного отношения к исходным данным.
Генератор учебных заданий положил «маши…ый» в правильную корзину, а проверка переложила слово в неправильную. При этом модель-арбитр в своём же объяснении написала «машинный». Разбираем по сохранённым ответам три сбоя проверяющей модели: что пошло не так в процессе, что поменяли в коде и чего эти правки не доказывают.
Код skillmem прошёл два независимых ревью, и я считал его чистым. Потом две модели с разных сторон — Claude и GPT — сорок раундов подряд читали его враждебно, обязанные воспроизводить каждую находку командой. Шесть P1 и около двадцати пяти P2 в коде, который «уже был отревьюен», и главный урок: каждый второй фикс рождал регрессию, которую ловил только следующий раунд.
