Осенью прошлого года мне на почту пришло письмо от Heisenbug. Предлагалось пройти опрос: рассказать, какими технологиями я как тестировщик пользуюсь, чем интересуюсь, на каких конференциях была, что слушала и так далее. За прохождение опроса я автоматически становилась участником розыгрыша билета на одну из конференций.
Для меня это ничего не стоило, поэтому я решила поучаствовать и довольно быстро про это забыла.
И тут под Новый год приходит письмо: «Вы победили в розыгрыше». Так у меня появился бесплатный билет на весенний Heisenbug 2026.
Расскажу про несколько докладов, которые мне запомнились, и про идеи, которые хочется попробовать у себя.
День открытия и «биполярное тестирование»
Конференция длилась два дня.
Примерно треть докладов так или иначе была связана с искусственным интеллектом. В общем-то ожидаемо.
В первый день мне понравилась вводная сессия. Ведущие и организаторы обсуждали, насколько плотно ИИ начинает входить в повседневную жизнь, чем помогает и какие опасения при этом вызывает.
Но больше всего мне запомнился другой момент.
В какой-то момент разговор зашёл про популярные виды тестирования. И среди них прозвучало… биполярное тестирование.
Я зависла. Такого вида тестирования я раньше не встречала, поэтому сразу записала себе на стикер: «погуглить».
А ведущие в это время посмотрели на реакцию зала и плавно увели разговор совсем в другую сторону.
О чём вообще шла речь
Сейчас на собеседование всё чаще приходит не только кандидат, но и его невидимый помощник в соседней вкладке.
Из-за этого всё сложнее понять, что человек знает сам, а что ему подсказывает ИИ.
Кстати, на эту тему был хороший доклад ещё на осеннем Heisenbug.
Именно отсюда и появилось то самое «биполярное тестирование». Не как отдельный вид проверки продукта, а как приём на собеседовании.
Смысл в том, что современные модели крайне неохотно говорят «не знаю». Если ответа нет, они часто начинают достраивать картину сами — иногда удачно, иногда нет.
Поэтому ведущие предложили довольно любопытный приём: задавать вопросы, которые могут загнать ИИ в тупик. Не для того, чтобы поймать кандидата, а чтобы понять, где заканчиваются подсказки нейросети и начинаются собственные знания человека. Об этом, кстати, был хороший доклад на осеннем Heisenbug.
Доклад Яндекса про измерение эффекта от ИИ
Один из самых интересных докладов был у Яндекса. Речь шла о том, как они пытаются измерять пользу от внедрения ИИ в процессы тестирования.
Доклад местами был довольно математическим. Некоторые формулы я честно пролистала мимо, но несколько практических идей себе всё-таки записала.
Больше всего мне запомнились три истории.
Первая — про регресс.
Меня порадовало, что начали именно с него. Кажется, регресс — боль почти любой команды.
Спикер рассказывал, что они сделали несколько агентов: один анализировал код, другой — интерфейсы. Позже эти подходы объединили. В результате около 66% регрессионных проверок у них сейчас выполняется с помощью ИИ, а остальное остаётся за людьми.
Ещё они автоматизировали подготовку чек-листов. Для генерации используются мердж-реквесты, описание задачи и внутренняя документация. На выходе получается готовый чек-лист, который прикрепляется к задаче.
Время подготовки сократилось не драматически, зато выросло качество тестирования. Это отражалось и на количестве возвратов в разработку, и на числе проблем, которые всё-таки доходили до продакшена.
Сначала чек-листы генерировались просто текстом, а потом появилась интеграция с TMS, и всё стало складываться туда автоматически.
Отдельно рассказывали про end-to-end тесты и вайб-кодинг. По их замерам, у тестировщиков, которые активно используют такие инструменты, время выполнения задачи сократилось примерно на 30%.
Для оценки они собирали статистику по действиям пользователей: сколько токенов потрачено, сколько времени работала модель и сколько ушло на исправление её ошибок.
Отдельно я записала себе Memory Bank. Раньше про этот подход я не слышала.
По сути это набор markdown-файлов с правилами и инструкциями: как писать код, как делать ревью, как оценивать возможность автоматизации тестов, какие практики приняты внутри команды.
Идея мне понравилась даже без привязки к ИИ. Такой набор правил вполне может пригодиться для онбординга новичков или просто как единое место, где собраны договорённости команды.
Как тестировать агентов: LLM как судья
Ещё один хороший доклад был про тестирование ИИ-агентов.
На примере бронирования билетов и гостиниц спикер показывал, где агенты чаще всего ошибаются, как возникают галлюцинации и какими способами можно проверять стабильность их работы. Причём речь шла не про ручное тестирование — для проверки ответов снова используется ИИ.
Заодно записала себе пару новых вещей на изучение: RAGAS и подход LLM as a Judge.
Тема показалась очень полезной для оценки промптов, особенно если они используются в реальных процессах и должны работать стабильно.
Вайб-кодинг без боли
Ещё был хороший доклад про вайб-кодинг.
Спикер рассказывал про работу в Cursor и похожих инструментах. Основная мысль была довольно простой: не стоит постоянно сидеть только в Agent Mode.
Для нормальной работы есть несколько режимов — Plan, Ask, Agent и Debug. И каждый нужен для своей задачи.
Потом показывали типичную ситуацию, когда разработчик или тестировщик просто бесконечно пишет в Agent: «переделай»,«не так»,«ты всё сломал».И так по кругу.
Тут я неожиданно узнала себя, потому что большую часть времени работаю именно так.
После доклада я попробовала сначала строить план, просить ИИ задавать уточняющие вопросы и только потом переходить к генерации. Разница оказалась заметной: код приходится переделывать гораздо реже.
Особенно полезным оказался этап планирования. Когда сначала появляется понятный план действий, его можно быстро проверить, поправить и только потом запускать генерацию кода. Это ещё и токены экономит.
Ещё понравилась идея с Playwright. Спикер показывал, как можно подключать его к ИИ-инструментам для создания и запуска UI-тестов. Агент получает доступ к браузеру, может переходить по страницам и взаимодействовать с интерфейсом.
Точно хочу попробовать это на практике.
Отдельно обсуждали исследовательское тестирование с помощью ИИ. Сценарий выглядит примерно так: агент получает user story, проходит по интерфейсу и пытается найти не только то, что описано в требованиях, но и дополнительные несоответствия.
На выходе можно получить список потенциальных багов, пропущенных требований и спорных мест, которые потом уже проверяет человек.
Про внедрение ИИ в небольших компаниях
Был ещё доклад про то, как ИИ внедряют не банки и корпорации, а небольшие команды.
Спикер много рассказывал про ограничения, которые возникают в маленьких компаниях, где нет огромных бюджетов и отдельных исследовательских подразделений.
Больше всего меня заинтересовал инструмент Roo Code, который показывали как альтернативу Cloud Code. Судя по демонстрации, он может работать с файлами на компьютере, но только в рамках заранее заданных ограничений.
А ещё они показали свой процесс по созданию UI-тестов: от анализа требований и подготовки тест-кейсов до генерации готовых автотестов.
На этом месте я записала себе простую пометку: «Это мне надо».
Приятное совпадение
Когда я просматривала программу Heisenbug (буквально в день конференции), я была приятно удивлена тем, что в составе программы был доклад «Ускоряем баг-репортинг с помощью самописного браузерного расширения». Буду честной — я его не посмотрела. Но испытала радость от того, что чуть раньше сама выступала с митапом внутри компании, где рассказывала ровно о том же: как писала расширение, встраивала туда искусственный интеллект, работу с формой и записью экрана для демонстрации проблемы.
Приятно иногда случайно обнаружить, что думаешь в ту же сторону, что и люди на профильной конференции 😌
Что хочется попробовать после конференции
добавить несколько вопросов на собеседованиях, которые помогают понять, где кандидат отвечает сам, а где за него начинает отвечать ИИ;
собрать свой Memory Bank с правилами для автотестов, ревью и чек-листов;
поэкспериментировать с подходом LLM as a Judge для проверки промптов;
перестать использовать только Agent Mode и поработать через связку Plan → Ask → Agent → Debug;
посмотреть на Roo Code и понять, насколько он может пригодиться в процессах моей команды.
Кстати, организаторы уже выложили записи осенней конференции на YouTube. Там тоже много интересных докладов — я себе уже несколько добавила в список на просмотр.