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

Среди выступлений он отдельно отметил доклад Ивана Лобашева о радикальном сокращении релизного цикла, в котором прозвучала формулировка о том, что отчёт по тестированию должен быть понятен пятилетнему ребёнку и даже разработчику. Сам Цепков выступил с концептуальным обзором того, как ИИ трансформирует отрасль, — это была переработка его более раннего доклада на конференции Joker, где фокус смещался в сторону разработки. На SQAdays акцент сделали на том, какие места в новой структуре ИТ могут занять тестировщики. В качестве одного из рабочих сценариев спикер описал подход SDD, при котором в спецификацию вместо технического дизайна закладываются acceptance criteria и тест-кейсы, передаваемые агенту для разработки. По сути, это развитие практик TDD и BDD, и в такой модели тестировщик естественным образом занимает роль прикладного разработчика. Если специалист уже работал с автотестами, у него есть представление о коде и интеграциях, поэтому освоение новой роли не потребует радикальной переквалификации. Аналогичная логика действует при разработке прототипов и вайбкодинге приложений на заказ — здесь возрастает потребность в аналитических навыках, которые у многих тестировщиков уже сформированы через взаимодействие с заказчиками и разбор инцидентов в рамках поддержки. Кроме того, тестировщики обычно хорошо представляют способы интеграции в рамках конкретного ИТ-ландшафта, что необходимо для вписывания создаваемых сервисов в существующую инфраструктуру.

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

Образ будущего, сформулированный Цепковым уже после выступления, в ходе обсуждений с участниками, выглядит так: нынешняя ИТ-разработка исчезнет, её поглотят соседние фазы. Появятся BusDev tiny-team, состоящие из бизнеса и технаря, который вайбкодит новый функционал и при необходимости выводит его в продакшн для A/B-тестирования, после чего передаёт DevOps-команде в конвейер поставки. Технарь в такой команде ищет технические решения, если идея не реализуется типовым сценарием, обеспечивает технологичное включение нового в существующий продукт и оппонирует бизнесу, поскольку в одиночку сильная реализация не рождается. Тестировщик может занять место как в BusDev-, так и в DevOps-команде в зависимости от предпочтений. При этом спикер оговаривается: такой образ будущего не означает, что все команды будут устроены именно так, — это лишь расширение спектра возможных способов организации ИТ.

Для российского рынка эти тезисы имеют особое значение, поскольку падение числа QA-вакансий здесь ощутимо опережает мировые показатели. В отрасли уже обсуждается траектория перехода от Manual QA через Automation QA и QA Lead к AI QA Engineer, ML Evaluation Engineer и далее к ML Engineer — и переход от оценки ИИ-систем к разработке оказывается заметно короче и естественнее, чем классический путь из тестирования в разработку. На фоне разговоров о том, что последний язык программирования уже написан и новые языки после 2010 года рождались под конкретные боли компаний, а не из академического интереса, вопрос о том, с чем останутся те, кто продолжит писать код, становится всё более практическим. Конференция показала, что ответ на него отрасль ищет не в теоретических дискуссиях, а в конкретных приёмах и пересборке ролей внутри команд. Остаётся открытым вопрос, насколько быстро такие изменения затронут массовый сегмент тестирования и какие новые компетенции потребуются от специалистов уже в ближайшее время.