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

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

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

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

Откуда вообще взялся классический QA-подход

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

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

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

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

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

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

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

Причем здесь эпоха ИИ?

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

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

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

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

Как должен меняться QA-подход

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

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

Меняется и роль команды. Я, правда, об этом и раньше говорила, еще года 2-3 назад, но я достоверно знаю, что многие до сих пор внутренне противятся этой мысли.

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

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

• 19 мая 20:00. «Критерии качества и безопасности AI-систем в продукте». Записаться

• 21 мая 20:00. «ИИ как ассистент QA: пишем API-тесты с нуля». Записаться

• 1 июня 20:00. «Мониторинг распределенных систем». Записаться