SQAdays: ИИ-трансформация и ценность качества

Отчет. SQAdays: ИИ-трансформация и ценность качества

Прошла очередная, 39 конференция SQAdays. Половина выступлений была посвящена использованию ИИ, и они носят вполне прагматичный характер освоения нового инструмента, который вошел в арсенал наряду с другими. Просто пока он новый – есть смысл рассказывать о способах его использования, чтобы поделиться этим с теми, кто еще не успел его освоить, рассказать о конкретных приемах. При этом отдельного трека ИИ не было, выступления распределены тематически: автоматизация, менеджмент, разнообразие тестирование и ИИ был во всех трех треках.

Дальше в конспекте у меня две большие темы – о трансформации ИТ-отрасли под влиянием ИИ по мотивам моего выступления и о сакральности понятия качества, по итогам круглого стола про его ценность. А потом, как обычно, конспекты выступлений, сначала – тех, которые посвящены ИИ, затем – остальных. Среди выступлений я хочу отметить выступление Ивана Лобашева о радикальном сокращении релизного цикла, и в нем прекрасная фраза об отчете по тестированию отчет должен быть понятен 5-летнему ребенку и даже разработчику.

И учитывайте, что у меня – малая часть выступлений: на конференции было три трека выступлений и трек мастер-классов, так что я был на малой части, тем более, что часть слотов пропустил, активно общаясь в кулуарах. Ведь именно такое общение – основной профит конференций, а выступления – можно посмотреть в записи.

Максим Цепков. Как ИИ трансформирует отрасль

Мое выступление тоже было посвящено ИИ, и носило характер концептуального обзора, анализа направлений развития ИТ-отрасли, попытке предсказать ее будущее и увидеть в нем те места, которые займут тестировщики, дать направления для эволюции существующей специализации. Это была пересборка выступления на Joker, где фокусом была разработка, а по ссылке есть краткие тезисы, а не только презентация. А здесь я соберу тезисы, которые касаются возможной роли тестировщика, которые распределены по выступлению.

1. Один из работающих вариантов SDD заключается в том, что вместо технического дизайна в спецификацию пишут Acceptance criteria и тест-кейсы, и в таком виде передают агенту для разработки, получается развитие TDD/BDD. В этом случае тестировщик естественным образом занимает роль прикладного разработчика. Если он работал с автотестами, то представления о коде у него есть, включая работу интеграции. Так что освоение новой роли будет не сильно сложным.

2. Аналогичная роль прикладного разработчика может быть при разработке прототипов или вайбкодинга приложений по заказу. Тут требуется большее количество навыков аналитика, но они у многих тестировщиков они есть – они взаимодействуют с заказчиком и пользователями для уточнения поведения системы в сложных случаях или разбора инцидентов в рамках поддержки. Кроме того, у тестировщиков обычно хорошие представления о способах интеграции в рамках конкретного ИТ-ландшафта, которые неизбежно потребуются для решения таких задач, чтобы обеспечить вписывание создаваемых сервисов в существующий ИТ-ландшафт.

3. После того, как для новой фичи или продукта вайбкодингом создан прототип или MVP, который прошел проверку на реальных пользователях в продакшн, это передается ИТ для развития и сопровождения. Его надо обвязать описаниями и тестами, проверить устойчивость и масштабируемость, и провести необходимый реинжиниринг, опираясь на гипотезы о притоке пользователей. В этой команде точно есть место нынешнему тестировщику, работающему с автотестами, особенно если он занимался аспектами устойчивости и масштабирования.

4. При агентской разработки есть задача мониторинга качества работы агентов и доработки harness в HADI-цикле. И это умеют делать тестировщики, если они работали с системами мониторинга нагруженных приложений в рамках нагрузочного тестирования и решения аналогичных задач. В рамках этих задач при большом масштабе разработки надо не только следить за текущими характеристиками, но и проводить апробацию различных моделей, а для этого нужно создавать наборы тест-кейсов и организовывать оценку. Эти задачи близки тестировщику, особенно если он работал с оценкой и тестированием ИИ-систем предыдущего поколения, например, рекомендательных системы выдачи рекламы и предложений пользователю или чат-ботов.

Мое выступление называлось «Как ИИ трансформирует отрасль», однако, сформулировать образ будущего получилось только после вступления, в ходе обсуждений с участниками. Вот он. Нынешняя ИТ-разработка исчезнет, ее съедят соседние фазы. Будут BusDev tiny-team, состоящие бизнеса и технаря, который вайбкодят новый функционал, при необходимости – выводя в продакшн для A/B тестирования, а затем – передают его DevOps-team в конвейер поставки, которая обеспечивает эксплуатацию, в том числе – доводя его по надежности и масштабируемости до требуемых параметров. Технарь в BusDev-команде нужен для поиска технических решений, если идея не реализуется типовыми сценарием, он также обеспечивает технологичное включение нового в существующий продукт, если для этого нужно создание новых API, а еще – он оппонирует бизнесу: опыт показывает, что идеи требуют обсуждения с хорошим оппонентом, в одиночку сильная реализация не рождается. Его компетенции сильно напоминают нынешних разработчиков прототипов, это, по-сути, отдельная специализация. Тестировщик может занять место в BusDev-команде, либо в DevOps-команде, в зависимости от предпочтений.

Впрочем, такой образ будущего не означает, что все команды будут устроены таким образом, это лишь расширение спектра возможных способов устройства ИТ и его включения в бизнес. Думаю, наиболее эффективный, но это не означает, что так будут устроены все команды. Роль эффективности сильно переоценена, история Agile-методов это хорошо показывает.

Хотя уже 20 лет известно, что наиболее эффективным способ организации разработки являются кроссфункциональные команды, которые обеспечивают высокую скорость доставки функционала. Что по-прежнему не мешает организации по функциональным отделам. И не только старым организациям: новый стартап, вырастая из одной команды тоже может превратиться в функциональную структуру, потому что основатели уважают старые учебники и полагают написанное в них – правильным. Да, со всеми проблемами такой структуры, в результате чего тестирование релиза начинает занимать две недели с практически остановленной на это время разработкой. Потом его успешно сокращают до двух часов, и это – замечательно. Об этом, в частности, было выступления Ivan Lobashev, и там показано место в такой трансформации ИИ-инструментов (раньше это делали без них, но с ИИ стало легче). Но что поступить так, когда тестирование начало занимать 2-3 дня, а не ждать, пока оно станет две недели, мне лично неясно. Как не сильно ясно, что мешает сразу строить кроссфункциональные команды, а не проводить трансформации позднее.

Так что, думаю, наряду с новыми компаниями по-прежнему будет существовать старые варианты, и тестировщики могут продолжать в них работать, естественно, включив ИИ-инструменты в свой арсенал.

Качество сакральное и прагматичное

На конференции был круглый стол «Остается ли качество ценностью в новых реалиях?». Ведущими были Сергей Атрощенков, Елена Щепеткова и Елена Допира, и активно участвовал зал. Участники разбирались, снизило ли нынешнее ускорение разработки и выкатки новых версий, которое обеспечивает ИИ внимание к качеству приложений. Мнения тут разделились, потому что кейсы, когда качество приносится в жертву скорости реализации, и на пользователя выкатывают относительно сырой релиз широко известны и раньше. Так что, вполне вероятно, внимание к качеству осталось прежним, а пользователи могут получать больше инцидентов просто за счет увеличения частоты релизов. С другой стороны, применение ИИ-разработки позволяет существенно увеличить покрытие тестами, на которое раньше не хватало сил и многие компании это делают.

Однако, возможности ИИ позволяют так же быстро проводить реинжиниринг и редизайн приложений, в результате чего знакомый интерфейс становится не привычным пользователям, а ценность изменений сомнительно. Но тут было отмечено, что большинство компаний оценивают пользовательский путь, и неудачные эксперименты откатывают. Хотя насколько это делают монополисты или обладатели значительной доли рынка – вопрос открытый. На круглом столе это явно сказано не было, но надо понимать, что в больших корпорациях работает механика мотивации: если новый дизайн признан удачным, то авторов ожидают премии, а если нет – то премий не будет даже при культуре толерантности к ошибкам, которая есть далеко не везде. Так что на практике отношение к оценке новшеств может быть очень различным, тут широкое поле интерпретаций и манипуляций.

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

Но уже в конце круглого стола я понял одну важную вещь – различное отношение к понятию качества. Для одних качество – это оцифрованная прагматична штука, которая меряется через количество допустимых багов и лояльность пользователя к продукту. А для других качество – это сакральная ценность, которая в таком качестве должна поддерживаться всеми компаниями безусловно, и оцифровывать, превращать в метрики ее не допустимо. Сакральное отношение явно проявлялась в высказываниях, в претензиях на то, что компании не заботятся о пользователе, дают не качественный продукт. При этом, по сути выступающие говорили о разном, хотя использовали одни и те же слова. Но это различие – не рефлексировали.

Наверное, это кажется слишком отвлеченным, так что я попробую проиллюстрировать примером из другой области. Есть тема гуманного отношения и заботы о животных. Все согласны, что бессмысленной жестокости быть не должно. Но вот дальше начинаются различия, касающиеся практики, которая ставит очень разные вопросы. Например, ваша домашняя собака заболела, и требует не двух прогулок утром и вечером, а 4-5, иначе гадит дома, что требует серьезной перестройки вашей жизни, например, переезда за город, где она сможет сама выходить на участок – готовы ли вы на это пойти, или лучше усыпить? Или теперь требует постоянного дорогого поддерживающего лечения – насколько вы на это готовы? Вопрос осложняется, если у вас много питомцев, и вы понимаете альтернативу: или вы содержите одного дорого, или 2-3 за те же деньги. А еще есть лошади, которых одни держат как личных животных-друзей, а другие – выращиваются в стадах для мяса: если лошадь-друг получила травму и вы не можете ходить с ней вечерами и в выходные по городу, получая доход, а должны платить за лечение – можно ли ее просто сдать на мясокомбинат, и купить другую? Или бездомные собаки, которые стали слишком агрессивными, так что есть риски нападения на людей – каковы к ним пределы гуманности?

Спектр вопросов очень широк, однозначных ответов нет, и позиции людей отличаются. И тоже одни исходят из сакральных представлений о ценностях, а другие – из прагматичных цифровых показателей. При этом попытки придти к консенсусу – бесполезны, надо жить и работать с людьми, у которых отношение различается. И с качеством – ситуация такая же. Как минимум, стоит представлять спектр позиций и уметь понять позиции собеседника. А потом – договариваться с ним о совместных действиях в конкретной рабочей ситуации. Потому что эмоциональные обвинения тут не слишком помогают конструктивному диалогу.

Я эту тему еще обсуждали после круглого стола, в том числе – с организаторами. Возможно, интересен отдельный круглый стол с таким фокусом.

Александр Соловьев и Иван Кузин. ТМС + Git: прозрачность в AI-тестировании

Фокус выступления – в обеспечении прозрачности тестирования за счет артефактов. Чат с агентом таким артефактом не является, к артефактом относятся документы: описания тест-кейсов и отчеты об их выполнении. При этом процесс организуется вокруг артефактов и строится таким образом, что каждый шаг процесса может быть выполнен человеком или ИИ-агентом, а формат артефактов при этом не менялся. Это дает гибкость процесса: для разных типов задач и в зависимости от ситуации исполнение может по-разному распределяться между агентами и людьми. При этом в выступлении много подробностей о том, как это организовано и как устроены агенты.

Описание тест-кейсов ведется на YAML и хранится в git. При этом используются snipped-шаблоны и описания типовых действий, чтобы уменьшить дублирование и copy-paste. Агент работает с таким описаниям, тестировщик тоже может это делать, но многим непривычно, поэтому сделан интерактивный редактор в IDE. Решение бесплатное.

Описания создаются в ветке и merge request проходит ревью, на который передают текст задачи, весь набор кейсов и глоссарий. И тут есть ловушка: если агента просто попросить сделать ревью – он одобрит, добавив пару low-кейсов. А если попросить быть построже – то завалит идеями. Поэтому для ревью сделали чек-лист: должны быть требования по кейсу, обязательно описание задачи задачи. Кроме того, определили, куда писать результат: его агент пишет не в чат, в комментариями к строкам в merge-request и добавляет итоговый вердикт.

По результатам ревью надо внести правки, это делает агент-фиксер. У него – дополнительные правила, чтобы отличить техническую правку от проблем, требующих дозапросов для определения точной работы программы.

Для запуска надо преобразовать тест-нейсы в ТМС. При этом YAML преобразуется в скрипт на python, Gherkin или другой формат, зависящий от платформы. Выполнение. Тоже ручное или автоматическое. Если агент – то обязательно скрины и логи, и проверяют их наличие.

Затем аналитика и разбор результатов. Это тоже может делать человек или агент-аналитик – он разбирает ночные прогоны. Анализ структурированных данных агенты хорошо делают, лучше человека – не устает и нет эмоций. Но! Классификация, и там обязательно надо сделать unknown – иначе агент дотягивает до конкретного класса, если не знает. А так у агента есть вариант. В правилах – чего не делать. Главное, решение принимает человек, поэтому нельзя писать «можно катить» и подобное.

Итого общий конвейер, git – TMC.

• Проверяемость: каждый шаг оставляет артефакт

• Точечный контроль: когда результат не устраивает – видим, гдесвернули не туда

• Нет точки отказа в виде ИИ – человек может выполнить любой шаг.

• Внедрять можно поэтапно.

Дмитрий Пуртов. QA automation после AI-трансформации: как меняется роль инженера

Компания разрабатывает софт для отелей. Дмитрий – QA-head и стремится автоматизировать и AI-зировать все что можно. В выступлении – конкретный рассказ об этом с кейсами.

Что значит AI-трансформация для отдела QA? Первое: берем ИИ и используем для всего что можно. И каждый пишет своего агента – ИИ-тулинг. После этого все 100% начали использовать, и даже упираться в лимиты. Но локальное ускорение – не изменило процесс. 5 дней тестирования как были, так и остались. Нужно перейти в новую модель производства.

Освоение новых технических средств всегда происходит по общему циклу: кейс → результат → переосмысление, затем – новая итерация.

Сначала – осознанность. Нужны базовые знание про ИИ. Вставили в матрицу компетенций и рассказали в отделе: как работает модель, что такое контекст и токены, ограничения и галлюцинации, базовый промптинг, проектирование проверок. Что дало? Меньше ситуативного промптинга, меньше непоняток с ответом, качественный входной контекст – люди понимают, как работает. Главное – изменение mindset: вместо сетований на LLM, понимание, что надо добиться от LLM, чтобы она делала как нам надо.

Затем – автоматизация, но по-новому: не алгоритм делать, а формировать цель, контекст, ограничения и критерии, чтобы LLM делало то, что нужно.

Что принесло? Они смогли препрыгнуть с Java на dotNet, делают аудит тестов – раньше на это не было ресурсов. Миграция всегда была возможна – но теперь стала дешева. Разработку кода отдали агентам. Люди делали архитектуру и код ядра. И делали ревью, особенно для бизнес-логики. Потому что assert(true), чтобы получить вечно зеленый тест вместо реальной проверки все видели.

Когда выбирали между xUnit или NUnit, то вместо сложных обсуждений теперь можно сделать два альтернативных решения, практически доведя до прода, чтобы пощупать на них технологию и на основе этого сделать выбор. Раньше такой подход тоже упирался в ресурсы.

Агент анализирует кодовую базу, документацию и прочее – и рассказывает как работает со ссылками на источники. Теперь не каждый вопрос надо нести в команду – агент отвечает, да еще он всегда смотрит в актуальный код.

А еще Shift-left стал дешевле, и агент лучше тестировщика это делает.

Все идет по единому пайплайну. Агент дает сигнал, и инженер – принимает решение. Навык инженера – агнетная разработка. Контроль: агенты освобождают руки, но нагружают голову.

Кинуть идею и получить автотест – не получается. Они пошли на улучшение, и метрика – дельта между первой версией и коммитом в мастер, достигли через тестирование агентов – и это – новая сфера. LLM – не детерминированый результат, автотесты в лоб не работают. Когда работаете с агентами, важно не допинать конкретную задачу, а сделать, чтобы агенты научились такие задачи делать.

Общий хаб для навыков. Локальные решения допустимы, но надо собирать. Tessa – платформа, где все собрано. И там каждый агент делает один QA, который горит этой темой. Новые навыки – управление множеством агентов.

.Итого: Осознанность – Автоматизация – Контроль. И два навыка: проектирование QA-gates и организация работы агентов. И появляется AI-конвейер разработки. Менеджеры видят, что он – без людей. А инженер рядом и достраивает конвейер. Это – будущее. И еще оценка Pre-Prod.

Но систему в целом надо удерживать. ИИ хорошо разрабатывает автотесты, однако надо удержать достаточность, не придти в ситуацию, когда продукт докручивают за час, а автотесты – еще день, потому что их много. Это вопрос к инженеру.

Вопросы остались. Как мерить качество агента? Почему недостаточно агента-контроллера, как тестировать автотесты, что они хороши? Что делать с разными контекстами? Какова будет роль инженера? Но есть продвижение.

Ivan Lobashev. Две кнопки до продакшена: как мы сократили релиз с 2 недель до 2 часов

Иван работает в стартапе в области ИИ, подробностей о продукте в выступлении не было, сказали лишь, что это два приложения и три платформы (Linux, Windows, Mac). А рассказ был о том, как они сократили время тестирования и выпуска релиза с двух недель до 2 часов. При этом речь не шла о том, чтобы полностью покрыть продукт автотестами, это дорого. Основная идея – в том, чтобы сместить максимум работы с регрессионного тестирования на этап пре-релиза, и при этом – сохранить уверенность в качестве. Потому что регресс при выпуске релиза останавливает конвейер, а с ветками фич и е-релизов можно работать параллельно.

Мне это выступление напомнило рассказы почти 10-летней давности от GetTaxi о том, как они обеспечивали конвейер continuous delivery. Средства – изменились, ИИ многое позволяет сделать проще, например, размечать тесты и код чтобы по merge request определить набор тестов для запуска на основе затронутого кода – тогда требовались более сложные алгоритмы, а теперь это запросы к моделям, и они делают. Но сама разметка тестов и кода – нужна. А еще у меня недоумение по поводу начальной точки: почему проблему начали решать, когда тестирование релиза начало приводить к двухнедельной остановке разработки, почему этим не занялись, когда оно стало занимать три дня. Но про это в выступлении не было.

А теперь – подробное содержание выступления.

На старте релиз занимал 2 недели, и все это время весь QA только релизил, это останавливало разработку. А они – стартап, им важно выпускать новое быстро. Поэтому цель – релиз каждый день, лучше – каждый час, и без привлечения QA, чтобы проблемы отсекались заранее. И средство – не 100% автоматизацию, это дорого, а задача была сделать максимально быстро.

Первое – изменение технологии: релиз проверяем не на main, а делаем копию, и все проверки идут на нем, если что-то не проходит – то патчи просто добавляем в релиз. Это обеспечило стабильный main и позволило построить QA gate на пути релиза.

Выделили три уровня готовности: основные сценарии работают, достигнут допустимый уровень проблем, идеал – все работает. Нет задачи обязательно довести до идеала. Это дало возможность перейти на smoke-тестирование. B на этапе пре-релиза (PR) должно быть обеспечено покрытие изменений smoke-тестами, и они все должны проходить.

Однако, запускать на PR полный набор smoke-тестов – сжирает кучу ресурсов. Поэтмоу придумали smart regression agent, который выбирает скоуп для прогона – что могло быть затронуто. Начали как soft gate, сейчас hard.

QA как гейты. Если есть изменения в тестах – QA проверяет. А еще в ревью встроили инструкции по проверке локаторов и прочего, и еще проверяли риски – и если они велики – то ставили тэг QA-тест, который отрабатывал человек.

Nightly-уровень – регресс после теста ночью. При этом оптимизация: не запускать прогоны, если не менялось. И сначала smoke, и полный – только если не упало. И отчеты летят в slack, и туда же летят метрики, и если превышение порога, например, тесты слишком долгие – тэгают. И еще – не все прогоны каждый день, потому что ломается не в одном.

Release-уровень – проверка RC. Смотрим, что менялось, для начала – пускаем smoke, при успехе – регресс. И регресс не запускается на всех платформах, ошибки только на одной – редкость. Похэтмоу у них каждый день mac – это основаня платформа, а windows и Linux – через день. B 10 шардов с изолированной системой, и запускаем данные по ним – параллельность. Сократили прогон до 40 минут. А дальше – анализ результата. Сначала анализ вел человек, потом научили агента искать проблемы.

Важно, чтобы QA gates для QA не просто выдавал флаг успех/провал. Из отчета должно быть понятно, в чем именно проблема. Для этого – агент анализа. А еще уведомления – не все подряд, а именно по существенным проблемам. И уровень проблемы: информация – soft (подозрение) – hard (блокировка). Важно, чтобы отчет был понятен 5-летнему ребенку и даже разработчику.

Отличие скрипта от агента. Когда пишешь pipeline и проверка – там жестко. А агенты умеют принимать решение, и там не так много работать.

Smart regression – прирост стабильности тестов. Механика такая: размечаешь тесты по темам (корзина, оплата и так далее). Дальше ты так же размечаешь код. Агент видит обе структуры, и в каждом pr смотрит изменения, и запускает нужные тесты. Обычно на тест или папку 3-4 тэга. Получается маленький прогон, но нужных тестов. И они ставили ограничения по числу тестов.

Агент по оценке результата тестов в релизе. Хорошо – риски (flake) – красные тесты (тоже надо определить порог). И агент кидает результаты в slack. Конечное решение – за человеком. Агент смотрит на историю тестов – насколько часто падает, это новая проблема, или старая и так далее.

И еще один интересный фактор задержки. После того, как ускорили тесты, стало задерживать создание release notes. Они – стартап, и их пользователи release notes читают. Их пишут продукты, и получилось, что тесты стали занимать час, а release notes – день, потому что продукт занят, попробовали написать скилл – не получилось, у ИИ не получаются нужные формулировки. Поэтому пошли другим путем: в фичах заранее пишут инфу для release notes и их важность, а потом агент собирает на их основе. Так заработало, продукт первые проверял, а потом – одобрил.

Метрики.

• Ежедневные. Pass/Failed, причины Failed, Flaky и причины, среднее время прогона, покрытие, PR-итерации тестов.

• Релизные: от старта релизов до конца, количество RC – сколько итераций для релиза, количество релизов и хотфиксов, ручное вмешательство – где потребовалось, high-инциденты после релиза.

• Метрики локализации проблем. У них не просто фронт и бэк, а есть еще модель, с которой могут быть проблемы. Инфраструктура – флаги, если проблема больше одного раза – тикет на девопсов. Бэк или Фронт. Тестовые данные или автотесты. Тестовые данные решили через шардирование. И надо понимать, в чем проблемы – данные, пользователи, не найден локатор (при этом проблема может быть не в локаторе), устаревшие тесты, флаки.

Еще интересный прием с покрытием тестами – как его посчитать? У них не было acceptance criteria и тест-кейсов – стартап. Поэтмоу пошли иным путем: на уровне PR создавать все тесты агентами или иным автоматом, из них smoke писали сразу, а остальные – not implemented. И их количество как раз подсвечивает разрывы…

Итого – три агента: smart regression, release анализ и создание release notes.От 2 недель с кучей скриптов – 2 часа, из них час гоняем тесты. Main и RC идут независимо. И проблемы не в релизе, а PR. И они не автоматизируют все. Критичный функционал – всего 30 тестов, и можно релизиться, а если проблемы medium – сделаем через пару дней hotfix, профит релиза выше.

Написание тестов – работа на smoke, капали, что хотя бы немного было в каждом релизе, и постепенно и разработчики писали, и тестировщиков добавляли. И метрика not implmented – она давит.

Руками ничего не проверяют, но сомнительные вещи раскатывают фича-флагом на ограниченную аудиторию.

Агенты запускаются по-разному, что-то в облаке, а что-то разворачивается у себя, smart regress сначала ходил на claude, сейчас – локально.

Олег Сороцкий. Организация системы агентских QA-инструментов

Это рассказ о том, как собирать набор ИИ-инструментов для тестирования, чтобы те, кто начинает проходить этот путь от ИИ-помощников могли действовать по шагам, понимая, что должно входить во фреймворк. Когда-то давно я слышал аналогичные выступления про сборку системы тестирования, смысл в том, что тебе рассказывают структуру функциональных мест системы, которые ты должен заполнить с учетом специфики проекта, и это упрощает задачу: ты можешь не думать над структурой. При этом конкретных инструментов в выступлении не было, потому что они зависят от проекта и его окружения.

Типы составных частей системы.

• Rule – правила общения, подгружаются автоматически. Надо понимать, что агент их не соблюдает жестко, подобно человеку, он может относиться к правилам творчески.

• Mcp-сервер – методы, к которым агент обращается для получения информации или выполнения действий, как клиенту. Это код, который выдает предсказуемый результат. И он скрывает чувствительные данные. При этом надо думать про безопасность – чтобы данные mcp-сервера не были использованы во вред без санкций. И не перегружать набор инструментов: часто конкретному агенту достаточно 2-3, а если при этом дать 10-15, то остальные занимают контекст, а агент начинает в них путаться

• Субагент – его вызывает главный агент для решения конечной задачи. При этом главный не видит деталей. Главное – сложная задача, разделение и изоляция контекста, чтобы не перегружать главного агента. Проблема – испорченный телефон, основной агент не видит деталей.

• Навык – skill, Набор инструкций для конкретных задач, например, чтоб завести инцидент – чтобы было в стиле, принятом в компании. Навык читается по необходимости, в отличие от правил. Но агент может нарушать, как и правила. Задача навыка – сократить промпт. Недостатки тут – избыточная декомпозиция – не надо делать правила для маленьких задач, которые агент и так делает – это часто ухудшает, а не улучшает решения и ведет к перерасходу токенов. Если задача маленькая – агент и так поймет. А еще надо понимать о конфликтах, иначе агент прочитает несколько и получит противоречия. В общем, все как с людьми.

Теперь собираем инструменты для нашей системы. Основное – контекст: его качество определяет качество решения. Действуем по аналогии с людьми при решении задачи: при создание тест-кейса инженер пойдет смотреть информацию по задаче, кодовую базу, спецификацию, внешний вид приложения, значит это нужно агенту. Контекст – не сжимаем, стараемся, чтобы задача сработала за одно окно, иначе идет деградация. Поэтому делаем компактные описания mcp-серверов, навыков и так далее.

С кодовой базой и спецификацией агенты работают из коробки. Трекеры и мессенджеры у них свои mcp, хотя тут тоже есть варианты из коробки. Свои сделаны сделаны для кастомизации и контроля доступа, там можно ограничить контекст, чтобы агент не получал много лишней информации, которая его запутает.

Дальше mcp доступа к таск-трекеру, документации, мессенджеру и системе тестирования был разобран отдельно. В частности, по мессенджеру они не предоставляют агенту поиск, он может ходить только к тредам, на которые получил ссылки из задачи. Кроме того, отдельно разделен доступ к текстовым сообщениям и получения скриншотов.

Интересно, что у них есть общий mcp-сервер для вики, и есть частное решение для тестировщика. Переход к частному инструменту экономит токены и убирает путаницу – тестировщику нужно меньше инструментов для доступа к вики, чем для аналитика.

Агенту важно понимать устройство web-интерфейса, и для этого у них построена отдельная локальная карта на основе исходников с mcp доступа. Карту строит не агент, а специальный парсер, который работает устойчиво и агент работает с ней, а не восстанавливает из исходных кодов, потому что это у LLM получается плохо.

При реализации mcp надо учитывать, что внешняя система или сам mcp может падать, и корректно обрабатывать проблемы.

По итогам – 23 инструмента, которые занимают 23к контекстного окна. Экономичность – важна.

Сделан отдельный субагент для поиска во внешних системах Ему доступ к трекеру, вики и мессенджеру – он извлечет саммари. Используется LLM среднего сегмента, слабые – не дочитывают. И субагент для поиска по репозиториям, тут уже можно использовать модель низкого сегмента, а не только среднего. При поиске важно обогащение терминов: они могут быть по-русски или по-английски, возможны синонимы и слэнг проекта. При поиске часто ходят по кругу, надо ограничивать количество документов. А еще агенты заменяют поиск догадкой, поэтому требуем источники.

Навыков – много. Набор навыков – зависит от задач тестировщика в каждой команде. В выступлении было несколько примеров.

Написание тест-кейсов: агент должен написать так, чтобы он выглядел правильно. Сначала – данные, потом – идем в систему тестирования, берем образец, потом ищем информацию, собираем описание, показываем пользователю и при одобрении – записываем.

Чек-лист – комментарий к таску. Тоже читаем задачу, делаем блоки регрессионных проверок. И цикл одобрения.

Работа с баг-репортами: завести, переоткрыть или обновить. Находим тест-кейс, собираем непокрытый контекст ,уточняем детали дефекта, проверяем на дубликаты – показываем пользователю и получаем одобрение.

Есть несколько действий, которые надо заблокировать. Первое – вопрос пользователю до чтения навыка, для этого потребовался жесткий блок, второе – поиск информации по продукту в интернете – там этих сведений нет, поэтому внешний поиск разрешаем только для общих запросов. Еще агент может просить что-то одобрить, но не показывает что именно – тоже запрещаем. Но при этом агенту нужен легитимный способ сказать «не знаю» на задачу, иначе он будет искать пути обхода запретов.

И дальше был пример работы агента над задачей – подробный протокол с поиском информации и результатом – смотрите презентацию.

Есть особенности в их использовании ИИ. Они не используют LLM для тестирования напрямую, вместо этого делают навык создания автотестов и их прогона – чтобы оставались артефакты. В skill создания теста есть создание прекондишн-данных, если они необходимы. Для теста – они описали правильное заполнение формата и получили результат.

При внедрении – были опасения сотрудников, но они показывали работу инструмента и опасения прошли. На первом этапе заставили всех написать 5 тест-кейсов. Этого оказалось достаточно.

Вадим Лунин из Альфа-банк. От хайпа к метрикам: реальный опыт внедрения AI в тестировании

В выступлении был подробный рассказ про pipeline тестирования, собранный на агентах, с рядом подробностей: форматы генерации, многоуровневая валидация результата, особенности перегенерации по замечаниям и так далее. Включая мониторинг качества решения задачи и усовершенствование инструмента. К сожалению, я слушал выступление не с начала, поэтому за деталями надо смотреть презентацию и запись выступления. Рассказ был не только про сам pipeline, но и про метрики, которых удалось достичь и решение проблем, в том числе – с безопасностью. У них – банк, так что вопрос безопасности важен, но они умеют его решать.

Внедрение шло поэтапно. Сначала – одна команду и use case для пилота, который согласован с безопасником, это 1-3 человека на 2-3 недели. Это – отработка технологии. Потом – отрабатываем повседневную работу, это тоже пилот на команду или несколько, для которого выбираем чемпиона из предыдущей, перестраиваем процессы и строим еженедельные метрики. Если удачно – расширяем. А дальше – тираж на компанию, чемпионы и лист онбординга должны быть готовы.

Внедрение с пряниками – обучение, безопасная среда, мотивация, пример чемпионов. Набили много шишек на внедрении без этого, поставив сразу задачу тестировщику – так не работает, у него проблем нет, хотя лид ее видит. И для начала – приходим к команде, и добиваемся признания, что боль.

Важно выделить время для внедрения, как для любого нового инструмента. А при тиражировании – обеспечить обучение и примеры. Внешние курсы есть, но их применить не получается, нужны собственные со спецификой. Ну и технические проблемы с доступом к моделям – решаем в рабочем порядке.

Владислав Григорьев. Путешествие на Восток за качеством

В выступлении – набор агентов и архитектура их взаимодействия для решения задачи покрытия сервиса тестами. При этом в задаче просто указывают сервис, а дальше агенты самостоятельно анализируют код сервиса и существующие тесты, составляют план доработок, а затем – его выполняют. Цель – покрытие тестами большое количество накопленных сервисов, по которым плохо с тестами и описаниями, конкретный тест агенты пишут хорошо, и спецификации на основе анализа кода создают, а теперь нужно было поставить решение этой задачи на поток.

Из интересных особенностей: потребовалось сделать разных агентов-разработчиков для анализа кода и для написания unit-тестов: оказалось, что в настройках для успешного анализа нужно ставить высокий уровень творчества (температуру), а вот написанию тестов по шаблону творчество агентов мешает. Соответственно, для этих агентов – свои оркестраторы, их тоже два, и поток задач делится между ними по типам задач.

В рассказе агенты – персонализированы с восточными именами, отсюда и название выступления. Система собрана на публичных китайских моделях разной силы: DeepSeek, Kimi, GLM, Qwen. Проверили GPT – они не дают прирост качества при нормальном pipeline. Вывод: узкое место не в интеллекте, а в детерминизме вокруг нее.

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

Первая задача понятна: анализ сервиса – назначение и интеграции. Затем смотрим, какие тесты есть, анализ покрытия, часть тестов есть. Дальше агенты пишут тест-план, тут все достаточно хорошо. Этот этап прошел за несколько дней. А вот с разработкой конкретных кейсов пошло тяжело. У них Есть стандарты: GWT (given-when-then), комментарии и названия шагов – только на русском, хорошие проверки, а не просто assert 200. И с этим – проблемы.

Он не писал скиллы с нуля, взял готовые – 60 штук, каждый в отдельности – нормальный. Но тогда требования дублируются – ИИ перестает соблюдать. Поэтому была ручная работа – обобщить скиллы и сделать свои, в соответствии со стандартами. Скиллы – разные, для написания и проверки кода – и стандарты написания кода вынес отдельно, чтобы не было дублей.

Но все равно, написание автотеста и переделка по ревью требовала большого количества итераций. Вот тут и оказалось особенность с настройками творчества, и для написания тестов был сделан отдельный агент с другими настройками, который хорошо следовал шаблонам, а не фантазировал. Так заработало, потом пришлось разделить и оркестраторов.

Но ревью – делает, но процесс такой же, как когда он шел за функциональными тестировщиками. Агент 90% кода пишет нормально и качественно – написаны стандарты, и агент их соблюдает.

Из особенностей: когда много агентов стали работать параллельно, выяснилось, что git не всегда корректно определяет конфликты в merge, теряли фрагменты кода. Пришлось написать дополнительные правила анализа.

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

Тесты надо не только писать, но и запускать. Есть unit и e2e. Юниты – white box, а e2e – black box, смесь UI и api. C юнитами все просто, а с e2e агенты хитрят: вешают skip-тесты, или проверку скипают, зеленый тест ничего не проверил. Были пустые then и прочее. Разрешили красные тесты, и сделали гейт анализа проблем: инфраструктура, контракт (агент сам правит), логическая нестыковака – эскалация, я разбираюсь – тест или логика изменились, если данных не хватает – пиши их рядом отдельно, тайминги – стабилизируем. В результате отчет с разметкой классов проблем.

Итого – 13 агентов, часть – простые, о которых он не рассказывал: explorer для аналитики и другие, где нет магии. На конкретной системе получилось за 2 недели сделать покрытие до 83%: 548 тест-кейсов и 15к строк кода. Биз ИИ задача на 3-5 месяцев. Нашли 25 багов за 2 недели, из них 20 минорные, 5 – логические (их исправляла разработка). Дальше разработчики продолжают использовать.

Когда выходит релиз – обновляют контекст и анализ создает новый план. Тест-кейсы могут удаляться или сохраниться, могут появляться новые. В пайплайне это есть, включая проверку на дубли.

Стоимость коробочного решения. DeepSeek 40$ + GLM 250$ – агенты помогали и сам писал. Решение универсальное для разработки – тиражирование на все команды, не только его задачи. Ушло на всю эту коробку месяца три плотной работы, и сейчас ей уже полгода широко пользуются , больше 100 человек.

Мария Ковригина. Игра престолов: как протестировать систему и не сгореть между двух огней

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

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

Подробно я пересказывать не буду, смотрите запись.

Любовь Чубова. Игры, в которые играют тестировщики: как развить софт-скиллы через теорию игр

В выступлении – страый добрый транзактный анализ Эрика Берна, книги «Игры, в которые играют люди» и «Люди, которые играют в игры» – до сих пор актуальны. Кстати, это реально так, мы как-то в паре с Ириной Матвеевой, психологом, устраивали интерактив по разбору кейсов из зала с целью продемонстрировать мощность разных моделей и побудить их изучать, и во вводной части у каждого был обзор разных моделей. Но первый же кейс был на модель, которую оба знали, но не упомянули, как раз из Берна: админ реально саботировал попытки построить процесс, потому что ему нравилось героически тушить пожары и получать за это плюшки. А в выступлении был набор не конструктивных игр, которые встречаются в работе и которые полезно уметь опознавать, и знать способы выхода из игры. И другой набор – игры, в которые можно играть, чтобы развить конкретные софт-скилл. При чем делать это можно внутри работы. Софт-скиллы – не талант, а привычка.

Не консруктивные игры.

1. «Да, но…» – обесценивание баг-репорта. «Все плохо…» и на предложения – отпуск, переподготовка, больше работать – отвечает, что невозможно. Ему нужны не предложения, а сочувствие, а варианты он и так знает.

2. «Пинок под зад». «Вы не так настроили стенд – это у вас кривые руки.»

3. Почему ты не спросил – бесконечные уточнения. Тестировщик проверяет кнопку отмены подписки, ОК. Оказывается, кнопка должна быть активной две недели, но это потерялось – а почему не спросил.

4. «Посмотри, что ты наделал» – публичные обвинения «из-за тебя упал прод»

5. «А я же говорил» – тестировщик предупреждал, что баг всплывет – и он всплыл. И он вместо того, чтобы разбираться говорит, «А я же говорил»

У кого закрывали баги с пометкой «не воспроизводится», или кто-то писал, искал аргументы, а потом решил не отправлять, потому что бесполезно.

И дело не в том ,что люди плохие – они играют игры. Мы думаем ,что обмениваемся фактами, а реально запускаем эмоциональный сценарий. Игры вскрывают механизм сценария в безопасной среде, можно увидеть слепые зоны и скорректировать.

Три эго-состояния. Родитель в позиции сверху, когда надо поучить и рассказать как надо, часто – из опыта. Человек может говорить нужные вещи, но если они из позиции сверху, то не воспринимаются, или воспринимаются в штыки. Взрослый – на равных, обсуждение конкретной проблемы. Ребенок – обижается, дуется, «назло маме отморожу уши». Надо отслеживать, в какой позиции ты находишься, ловить себя и пробовать переключиться. Кажется это сложно, но тут как с обучением на механической коробке передач – через несколько дней учишься. Запретить быть токсиками нельзя, но надо за собой следить и переходить в роль взрослого.

Игры-тренажеры.

1. Глухой телефон – устная передача бага по цепочке. Три передачи, и оказывается, что абсолютно разные вещи, одни и те же слова интерпретируем по-разному. Игра решает проблему отсутствия в документации. Например, не приходит письмо на почту, разработчик проверил – ОК, баг закрыли, что не подтвердилось. Оказалось – проблема, если адрес заглавными буквами, а деталей в описании бага не было.

2. Угадай приложение. Цель – научиться задавать грамотные вопросы. Один человек загадывает приложение, остальные спрашивают вопросы, где ответ Да-Нет, можно с таймингом для динамики. За минимальное число шагов максимум информации. Проблемы: пробелы в сборе требований при максимуме информации. Пример: разработчик говорит «осталось прикрутить валидацию», ответ «стандартно» – а оказалось ,что длину строки проверяют, а спецсимволы – нет. Привычка уточнить, даже если не понимаю.

3. Черный ящик. Объяснить сложные термины простыми словами. Что-то техническое бабушке или первокласснику. Один получает карточку с термином (контейниризация или api), задача – объяснить, а остальные угадывают. На метафорах. Напрмиер, API – на примере официанта, который несет заказ клиента на кухню. С особыми случаями (кухня сгорела). Игра учит формулировать сложное простым языком. И они еще глоссарий сделали.

4. Родитель-взрослый-ребенок. Выходить из конфликта через осознание роли. Понять роль и перейти во взрослого. Часто в команде перебрасывают ответственность: у аналитика плохие требования, тестировщик плохо тестирует, а разработчик плохо пишет код. Игра учит относится с коллегам с уважением. Работает не всегда, не панацея. Можно попробовать.

5. Признание. Давать конструктивную обратную связь без шаблонов. Похвали коллегу за 3 вещи за последнюю неделю. Без общих слов. Реальное признание, «вклад любого винтика важен и нужен».

Как можно внедрять игры? Можно использовать ретроспективы. Или онбординг с ментором – особенно угадай приложение, чтобы разморозить задавание вопросов, или рассказать сложные термины. Или пятничные митапы.

Метрики. Пользу можно посчитать – посчитать выбранные критерии до и после. Например, число уточняющих вопросов, скорость закрытия багов, оценить число конфликтов на созвонах, количество благодарностей. Они спорили на созвонах, внедрили, им зашел черный ящик.

Когда пользы от игр не будет?

• Они не вылечат токсичную атмосферу, не уважение и выгорание.

• Когда проблема не в коммуникациях: плохая архитектура или не хватает сотрудников

• Игра для галочки

• Не делаем выводов: основная цель – рефлексия после игры

• Если кто-то против – их лучше не брать

Инструмент для относительно здоровой команде, чтобы стать сильнее. А не той, которая пытается не развалиться.

И еще примеры игр с рабочими примерами.

• Попался – ловят на ошибке

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

• Посмотри как я старался – фокус на усилиях, а не результате;

• Шум – эмоциональная эскалация на созвоне.

И много других, в презентации – QR-код на списко.

Софт-скиллы – не талант, а привычка.

Из вопросов.

• Если человек в роли родителя – вопрос к самому человеку и его целях. И начальники – не всегда в роли родителя, есть разные, а если у кого-то родитель – можно искать других.

• Примеры терминов из словаря: userstory писали по-русски и по-английски, кнопки – радио-кнопки или переключатель и так далее.

• Про поглаживания – если хвалишь за реальные факты, то формально не похвалишь.

Павел Щедухин. Кто проверяет решения руководителя?

Очень любопытное выступление про одиночество руководителя, который не может придти посоветоваться о решении, потому что это уронит его авторитет, но при этом нуждается в советнике-оппоненте для обсуждения решений. И идея для тестировщиков – попробовать стать таким советником-оппонентам, потому что профессиональные умения для этого есть: тестировщик умеет сомневаться, строить гипотезы, придумывать и оценивать метрики и так далее. И это – из личного опыта, Павел работает руководителем более 10 лет, совершил десятки ошибок, о которых не сказали.

Руководитель что-то решил, велит делать – и мы делаем, он руководитель. Мы не задумываемся, что он мог ошибиться. Решение руководителя никто не проверяет. Он спрашивал своего руководителя – тот тоже не проверяет.

Мы – тестировщики, мы все проверяем. Кроме решений руководителя. Почему так? Ведь Ошибки совершает кто угодно, и руководитель тоже. Но ему почему-то не говрят. А ошибки руководителя сильно дороже. Инженер написал функцию неправильно – переписали. А руководитель выбрал неверный фреймворк – там недели и месяцы.

Как руководитель принимает решения? Интуитивно. Именно так оно работает. Почему?

Представьте: хороший руководитель – какой? Справедливый, рассудительный, слышащий. Эго – главный баг лидера, когда он думает от себя и не советуется. Бывает токсичное эго – когда обесценивает достижения сотрудников, перекладывает вин: я прекрасно придумал, а они сделали фигню.

Эго руководителя исправить нельзя. Но можно защитить себя: фиксировать договоренности, возвращать ему риски (ответственность не на мне, а не всем отделе), и не принимать близко к сердцу (это не вы плохой, а он токсичный).

Руководитель – тоже челвоек. У него есть страхи. В их числе – страх оказаться неправым, показать неуверенность. Руководитель может переживать, может что-то идти не так. Но от него ожидают, что он все делает правильно. А еще руководитель не спрашивает, потому что боится, что видят неуверенность.

Как обсуждать решения руководителя?

• Нельзя говорить «это плохая идея». Спрашиваем – а что еще можно попробовать

• Нельзя говорить «это не сработает», а спрашиваем «как поймем, если это не сработает»

• Нельзя говорить «я вам говорил» – нам не нужен триумф, нам нужен баг репорт, чтобы система работала.

У руководителя проблема – отсутствие с человека со вторым мнением. Руководители одиноки, линейным сотрудникам проще обсуждать, руководителю не с кем обсудить. Некому тестировать руководителю.

Эту помощь мы делаем не для руководителя, а для его решений. Эти решения влияют на команду и на компанию. Проверить решение, до того, как оно стало проблемой – тестировать тикеты, до того, как ушло в релиз.

Есть red team – команда внутри компании, которая атакует безопасность. Тестировщики могут быть red team для руководителя – потому что им не надо этому учиться. Мы можем делать гипотезы, ломать позитивные сценарии, искать границы, искать побочные эффекты, проверить успех, как откатить и так далее, и это применимо к менеджерским решениям.

Не надо говорить «делаем не так», надо задавать вопросы и помогать проверить решения.

Например, руководитель пришел с идеей «поменять TMS». Вопросы: насколько быстрее, есть ли миграция, будет ли работать в нашей среде? Что будет, если импорт упадет, ключевые тэги не мапятся, интеграция с багтрекером не сработает? Переносить ли все архивные проекты, что делать с ручными тестами (бывает, что TMS на них не рассчитана)? Побочные эффекты: замедление продуктивности, разработчики не найдут кейсы, двойной ввод данных на миграции. Количество кейсов, время прохождения run, отсутствие инцидентов по tms. Сможем ли вернуться к старой, есть ли скрипт переноса, есть ли триал по оплате?

Что делать, если руководитель помощи не хочет? Можно пытаться помочь, но нас могут наказать. Что бывает, если QA наказывают за баги? Их становится меньше, но только на бумаге. Что делать? Надо быть мягче, руководитель – такой же человек, с ним надо говорить аккуратно, вопросы не публичные, а на подумать. Начинать с малых вещей, чтобы он понял, что помогаете, завоевывать авторитет. Можно искать союзников – если вы один накидываете – это странно есть коллеги.

Решения руководителя тоже нужно проверять. И для этого не обязательно знать правильный ответ, надо спрашивать «а что если?» Действовать надо аккуратно, чтобы руководитель подумал, что это он сам подумал, а не мы ему подсказали…

Как быть, если руководитель все время давит «делайте больше»? Руководителю можно объяснить, что вы не успеваете, и нужно – но быть готовыми разобрать, и, более того, он может что-то выкинуть – это его опыт. Это правильнее, чем если молчать, но не сделать. Руководитель обычно не говорит «делайте в субботу», он говорит «делайте быстрее» – и эту ситуацию тоже можно разбирать, и либо придумывают способ, или планируют рефакторинг для ускорения или что-то еще.

Классный руководитель, который все продумал – это как классный разработчик, который работает без ошибок. Их не существует, ошибки бывают у всех. И надо помогать их исправлять.