Выживут ли QA? Кто будет отвечать за качество?

Привет, Хабр! Меня зовут Михаил Новотарский, в Сбере я руковожу внедрением ИИ-практик в трайбе внутренних продуктов Workspace примерно на тысячу человек, а ещё развиваю профессиональное сообщество тестировщиков.

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

Обсудим четыре темы:

• как меняются команды;

• какие роли появляются;

• почему растёт когнитивная нагрузка;

• как подготовиться к этим изменениям.

И хотя разговор начнётся с QA, многие выводы применимы к аналитикам, разработчикам и менеджерам.

От идеи до результата

Давайте посмотрим на классический процесс разработки. Он начинается с идеи и проходит через несколько этапов:

1. исследование;

2. планирование;

3. проектирование;

4. разработка;

5. тестирование;

6. выпуск результата.

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

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

А потом все они упираются в препятствия:

• нужно согласовать результат;

• передать контекст;

• проверить решение;

• дождаться утверждения;

• разобраться, кто отвечает за ошибку.

Получается, что узкие места никуда не исчезли. Они просто переместились из отдельных операций в интеграцию между людьми и инструментами. Поэтому мало «добавить ИИ» в существующий процесс, придётся менять организацию работы. Давайте разберём, как меняется классическое представление о команде и ролях в ней в новых реалиях

От «двух пицц» к Product Builder

Начнём с базового представления о команде. Классическая продуктовая команда — это продукт-менеджер, технический лидер, аналитики, разработчики и тестировщики. Обычно её размер пытаются ограничить «правилом двух пицц»: команда должна быть достаточно маленькой, чтобы её можно было накормить двумя пиццами.

Исследования McKinsey показывают, что под влиянием ИИ такие команды начинают меняться. В них по-прежнему остаются продукт-менеджер, техлид и разработчики, но каждого из них усиливают специализированные агенты, а другие роли переходят в разряд сервисных, также усиленные агентами (это одна из гипотез). Одновременно возникает новая роль — Product Builder.

У LinkedIn для похожей роли использовали термин Full Stack Builder. Если Full Stack Developer умеет работать с фронтендом, бэкендом и средой развёртывания, то Full Stack Builder дополнительно умеет собирать решения из готовых компонентов и активно использовать ИИ, реализуя по сути весь процесс разработки самостоятельно.

Ключевое отличие — продуктовое мышление. Оно становится важным не только для продукт-менеджера, но и постепенно распространяется на все роли. Главная ценность продуктового мышления в смещении фокуса с кода на конечную ценность для пользователя.

В некоторых компаниях в Full Stack Builder пытаются превращать продуктовых менеджеров, аналитиков и проект-менеджеров, потому что они хорошо понимают продукт, пользовательскую ценность и бизнес-контекст. Если дать им правильные инструменты и набор «строительных блоков», то они смогут закрывать бо̒льшую часть пути от идеи до работающего решения. Код при этом становится не единственным и даже не главным аспектом разработки: фокус смещается на постановку задачи, спецификации, контекст и проверку результата. Подробнее послушать об опыте LinkedIn можно здесь.

Маленькие команды и разработка через намерение

Выше упоминал, что как раз коммуникация между большим количеством участников становится узким местом, поэтому один из важных трендов — переход к «маленьким командам» (tiny teams), минимальным по размеру продуктовым командам, которые отвечают за полный цикл разработки продукта или инициативы, а значительную часть ручной работы выполняют платформы и агенты. Такие команды могут делать больше, не увеличивая свой штат пропорционально объёму задач. Если раньше для запуска в пять раз большего количества фич требовалось примерно в пять раз больше людей, то теперь масштабирование всё чаще происходит с помощью автоматизации и ИИ.

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

1. люди формируют и уточняют спецификацию;

2. агенты быстро превращают её в результат.

Человек может несколько дней обсуждать, уточнять и переписывать намерение. Агент при этом выдаёт рабочий результат за минуты. Очень подробно и интересно это описано в Whitepaper AI Disrupt PDLC от Сбера (Кирилл Меньшов).

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

И здесь появляется неудобный вопрос: где в такой схеме находится QA?

Где теперь тестировщик?

Если продукт создают с относительно гарантированным качеством, то зачем нужен отдельный тестировщик? Почему результат не может проверить аналитик или разработчик? На схемах новых процессов QA иногда превращается в небольшую сервисную команду, которая обеспечивает качество сразу для множества продуктовых команд. Технологически это уже возможно. Но большинство компаний пока не работает таким образом. Между потенциальными возможностями технологии и её реальным применением возникает adoption gap — разрыв между возможностями технологии и её фактическим использованием в организации. Это нормально. Не все обязаны быть первыми. И это нормально, что не все принимают новое сразу.

Существует теория диффузии инноваций (её описал Эверетт Роджерс), в которой люди делятся на пять групп:

• новаторы: первыми пробуют новые технологии, даже когда они сырые;

• ранние последователи: быстро подключаются и помогают развивать подход;

• раннее большинство: ждёт понятного эффекта, метрик и доказательств;

• позднее большинство: переходит, когда технология становится стандартом;

• отстающие: не меняются даже тогда, когда прежний подход уже перестаёт работать.

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

От тестировщика к Quality Builder

Но вернёмся к тестировщикам. Эволюция этой роли выглядит примерно так:

1. manual QA;

2. automation QA;

3. full stack QA;

4. Quality Builder (термин я придумал сам на основе описанного выше Quality Builder).

Термин Quality Builder не является устоявшимся стандартом — это, скорее, рабочая модель, но она хорошо описывает направление изменений. Quality Builder умеет не только писать и запускать тесты. Он проектирует систему контроля качества, управляет агентами, понимает архитектуру продукта и оценивает риски.

У этой роли можно выделить четыре крупных блока компетенций:

1. архитектура контроля;

2. оркестрация агентов;

3. мультидоменные и фундаментальные знания;

4. управление сложностью.

Предлагаю рассмотреть каждую из них подробно.

Архитектура контроля

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

• где агент работает автономно;

• где требуется ручная проверка;

• какие решения нельзя выпускать без человека;

• какие ошибки допустимы, а какие — нет.

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

1. пользователь не может перевести деньги другому человеку;

2. злоумышленник может воспользоваться уязвимостью и украсть деньги.

Оба дефекта серьёзные, но их последствия различаются. В первом случае пользователь, возможно, попробует повторить операцию. Во втором — компания сталкивается с прямыми финансовыми потерями, расследованием и репутационным ущербом.

Поэтому тестировщик должен уметь не просто находить ошибки, а отвечать на вопрос: какая ошибка опаснее и почему?

Помимо этого есть вопрос: а как замерять работу ИИ‑агентов? У них есть технические метрики:

• скорость ответа;

• доля успешных выполнений;

• стабильность;

• количество обработанных задач.

Но этого недостаточно. Нужно измерять и качество самих ответов:

• насколько они правдивы;

• насколько безопасны;

• насколько устойчивы к ошибочному контексту;

• можно ли воспроизвести результат;

• понимает ли агент границы своей уверенности.

Например, чат-бот может корректно ответить на вопрос, как отключить антивирус. Формально проблема пользователя решена, но с точки зрения безопасности это может быть крайне плохой ответ. Поэтому «ответ работает» и «ответ безопасен» — разные характеристики.

Оркестрация агентов

Вторая важная компетенция сегодня — оркестрация агентов. Нужно понимать, как разбивать задачу и какой агент за что отвечает. Полный процесс работы тестировщика может выглядеть так:

1. прочитать требования;

2. проверить их на противоречия;

3. нормализовать формулировки;

4. выделить сценарии;

5. написать тестовые сценарии;

6. создать автотесты;

7. запустить тесты;

8. проанализировать результат;

9. проверить;

10. передать выводы команде.

Если поручить всё одному агенту, то результат часто будет слабым. Проблема не обязательно в модели. Обычно задача просто слишком большая и плохо декомпозирована. Разберём один понятный сценарий.

Генерирование тестовых сценариев и автотестов

Один из практических сценариев выглядит так:

• в систему загружают требования из Confluence или документов;

• агент анализирует их, возвращает замечания и просит уточнения;

• формирует нормализованную версию требований;

• после подтверждения генерирует тестовые сценарии.

Для этого вместо одного большого агента используют мультиагентную систему:

• центральный core-агент;

• несколько специализированных субагентов;

• отдельные циклы проверки требований;

• повторная оценка согласованности и полноты.

Может казаться, что задача простая: прочитать требования и написать тесты. Однако потом нужно будет ещё проверить их на наличие противоречий, пропусков, зависимостей и неоднозначностей. И всё же с помощью мультиагентной системы сегодня можно примерно за десять минут сделать то, на что раньше тестировщик тратил день или два — при условии, что система правильно спроектирована и результат проходит проверку.

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

• архитектуру проекта;

• правила именования;

• структуру тестов;

• используемые библиотеки;

• соглашения команды;

• паттерны фикстур;

• требования к проверке;

• ограничения CI/CD.

Для этого нужны правила и контекст проекта — своего рода база знаний, описывающая, как именно должны выглядеть тесты и каким критериям они обязаны соответствовать.

И здесь меняется сама работа QA. Мы постепенно перестаём вручную писать тестовые сценарии и автотесты. Вместо этого начинаем проектировать решение, настраивать агенты, формулировать правила, оценивать результат и управлять рисками.

Примеры подобных реализаций для генерирования тестовых сценариев и автотестов. 

Презумпция недоверия

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

• как получен результат;

• на каких данных он основан;

• какие проверки уже выполнены;

• что осталось за пределами контекста;

• насколько дорого будет ошибиться.

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

Промпт-инжиниринг и фундаментальные знания

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

• цель;

• ограничения;

• контекст;

• формат результата;

• критерии качества;

• условия остановки;

• правила обработки неопределённости.

Хороший промпт — это не магическая формула, а качественно сформулированное требование. По сути, ИИ не просто усиливает специалиста, он улучшает качество постановки задачи. И если задача сформулирована плохо, то агент быстро произведёт много некачественного результата.

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

Мультидоменные и фундаментальные знания

Quality Builder должен понимать систему целиком: как устроена её архитектура, как компоненты взаимодействуют между собой и какое поведение ожидается от продукта. Если раньше тестировщик мог отвечать за отдельный участок системы — проверить функциональность и передать результат дальше, — то теперь этого недостаточно.

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

Второй важный навык — понимание бизнеса. Нужно знать, какую ценность создаёт продукт, какие у него ограничения и какие последствия могут иметь ошибки. Поэтому QA постепенно поднимается на уровень продукта: важно понимать не только что сломалось, но и что это означает для бизнеса и пользователя.

Получается, что Quality Builder выходит за рамки одной специализации. Ему не обязательно становиться экспертом во всех областях, но он должен обладать достаточной фундаментальной базой, чтобы разговаривать с разными специалистами на одном языке, понимать архитектуру продукта и принимать решения с учётом бизнес‑контекста.

Когнитивная нагрузка

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

• не галлюцинация ли это;

• не пропущен ли важный сценарий;

• соответствует ли результат требованиям, не нарушены ли ограничения;

• безопасно ли это решение и можно ли ему доверять.

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

Есть и другая проблема — параллельное потребление информации. Мы одновременно участвуем во встрече, отвечаем в почте, читаем сообщения и проверяем уведомления. Так когнитивная нагрузка становится ещё выше.

Есть несколько простых, но рабочих практик по уменьшению когнитивной нагрузки:

• выносить задачи и мысли из головы во внешний список;

• приоритизировать входящие запросы;

• не работать параллельно во время встреч и сложных задач;

• сокращать информационный шум;

• выделять время для восстановления;

• регулярно проверять, какие решения вы принимаете сами, а какие бездумно отдаёте агенту.

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

А теперь посмотрим на те навыки, которые необходимы абсолютно каждому специалисту в ИТ.

ИИ-грамотность как новая операционная система

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

• архитектура задач;

• понимание применимости ИИ;

• презумпция недоверия;

• знание ограничений контекста;

• понимание обучающих данных и смещений;

• этика и безопасность.

Не каждую задачу стоит отдавать ИИ. Нужно понимать, где агент действительно эффективен, а где лучше не тратить свои ресурсы.

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

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

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

Традиционная модель обучения выглядит так:

1. изучить новый материал;

2. углубить знания;

3. применить их на практике;

4. столкнуться с ошибкой;

5. разобраться в причине;

6. адаптироваться к новым инструментам.

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

Так что будет с QA?

ИИ — это не отдельная функция, которую можно добавить в существующий процесс. Он постепенно меняет саму структуру разработки. Quality Builder — рабочая модель роли, которая объединяет:

• тестирование;

• автоматизацию;

• инженерное мышление;

• продуктовое понимание;

• проектирование контроля;

• оркестрацию агентов;

• управление рисками.

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

Конечно, невозможно будет директивно заявить: «С такого-то числа все становятся Quality Builder». В крупных компаниях подобные изменения могут идти через формализованный трек:

• описать будущую роль;

• определить необходимые навыки;

• составить программу развития;

• дать людям время на переход;

• измерить результат.

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

Итог

В эпоху ИИ тестировщик не исчезнет, но его роль станет шире, сложнее и заметно менее похожей на классическое тестирование. Самыми важными навыками станут ИИ-грамотность и адаптивность. Quality Builder будет:

• создавать контуры контроля;

• управлять мультиагентными системами;

• оценивать стоимость ошибок;

• понимать продукт и архитектуру;

• проверять работу агентов;

• принимать решения в условиях неопределённости.

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

Ну и, надеюсь, за время чтения вы успели познакомиться с Бажком — маскотом нашего сообщества, который сопровождал нас на протяжении всей статьи. Кажется, теперь он знает о Quality Builder не меньше нас.

P. S. В конце хочу поблагодарить коллегу и лидера ИТ‑хаба Сбера в Санкт‑Петербурге Андрея Власова за помощь с рефлексией по теме и идеями для статьи.