Классический QA умирает. Что приходит на смену

Классический подход к качеству строился вокруг простой картины мира. Есть требования, есть логика системы, есть разработка, есть тестирование. После всего этого продукт считается проверенным и готовым к эксплуатации. Базовая идея звучала так:

Если мы достаточно хорошо проверили систему до релиза, можно в разумной степени доверять её поведению после релиза.

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

Откуда взялся классический QA

Если отбросить романтику, классический QA вырос из мира относительно предсказуемых систем. Логика приложения была фиксированной. Интерфейсы менялись не каждый день. Входные данные были ограничены. Релизы выходили реже. Поведение продукта определялось тем, что в него явно заложили разработчики.

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

Но в её основании лежали допущения, которые сейчас перестают работать:

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

Где допущения рассыпаются

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

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

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

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

Причём здесь ИИ

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

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

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

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

Качество как траектория, а не как состояние

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

Тогда задача качества состоит не в том, чтобы один раз доказать корректность, а в том, чтобы:

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

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

Что меняется в работе команды

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

какие ограничения удерживают систему в приемлемом состоянии,
что считается сигналом деградации,
кто отвечает за обнаружение и реагирование.

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

Итог

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

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