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

Немного контекста

И снова на связи Роман Черепанов, инженер по автоматизации тестирования Cloud.ru. В QA пришел из телекома: работал у провайдера, затем тестировал сетевое оборудование и инфраструктурное ПО. Сейчас наша команда разрабатывает Kubernetes CNI-плагин, а я строю для него процесс тестирования. Как это выглядит на практике, я уже рассказывал в отдельной статье.

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

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

Что я понял из исследований

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

Например, в опросе SmartBear участвовало всего 273 специалиста и руководителя, связанных с качеством ПО. Исследование показало, что ускорение разработки с помощью ИИ уже вызывает опасения:

• 70% респондентов обеспокоены тем, что качество ПО страдает из-за роста объёмов и скорости написания кода с помощью ИИ.

• Ещё 60% сообщили, что за последний год сталкивались с проблемами качества ПО, поскольку разработка, ускоренная ИИ, опережала тестирование. 

Но в работе нет вывода в духе «70% программ стали хуже». Скорее, тут собраны опасения и опыт специалистов — сведения полезные, но не совсем релевантные.

В исследовании Tricentis за 2025 год опрошенных больше — 2750 человек из десяти стран. 

• 63% признали, что выпускали код без полного тестирования.

• 45% ставили скорость поставки выше качества. 

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

Попробуем посмотреть на проблему через деньги. По оценкам Consortium for Information & Software Quality (CISQ), в 2018 году потери экономики США из-за низкого качества ПО составляли около $2,84 трлн, а в 2022 году — $2,41 трлн. В расчетах учитывались не только программные сбои, но и затраты на устранение дефектов, технический долг и другие проблемы.

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

Если CISQ выпустит аналогичный отчёт за 2026 год, можно будет оценить, как изменились экономические потери за период массового внедрения генеративного ИИ. Но и тогда останется вопрос: какая часть изменений связана именно с ИИ, а какая — с другими факторами? Пока данных для такого вывода недостаточно.

Зато ситуации, о которых говорят респонденты, мне до боли знакомы.

С какими дефектами я сталкивался до ИИ

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

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

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

У нас расстояние между оборудованием было около десяти метров, в реальной сети — могли достигать нескольких километров. Проверки не учитывали эту разницу. Да и попробовать внести дополнительный шум было бы непростой задачей, потому что нужного оборудования катастрофически не хватало, а купить дополнительное — обошлось бы в копеечку. Разработчик исправил работу с сигналом, а технический лидер заказчика затем лично разбирал мой тест-план. Признаться, объяснять ему на ломаном английском, почему мы пропустили дефект, было некомфортно. 

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

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

Что изменилось с появлением ИИ

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

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

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

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

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

Как я проверяю качество в своей команде

Для своей команды я бы заменил прямой вопрос «У нас, что, кризис?» на три более приземленных (и менее пугающих).

Что стало происходить с пользователем? 

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

Выдерживает ли процесс нынешний темп? 

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

Почему серьезный дефект прошел через проверки? 

Разбираем не только ошибку в коде, но и путь до пользователя. Требование поняли неправильно? Не было нужного стенда? На регресс не оставили времени? 

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

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

К какому выводу я пришел

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

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

А какие тренды в разработке и QA заметили вы? Делитесь мнением в комментариях!