QAOps: как объединить QA и DevOps, чтобы ускорить релизы без потери качества

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

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

Мы полгода собирали данные: анализировали метрики, общались с командами, изучали отчёты – от международных (DORA, GitClear) до российских опросов. И теперь готовы поделиться выводами, которые можно сразу применять в работе – без абстрактных советов и обещаний мгновенного результата. 

Что такое QAOps?

Официального определения QAOps нет. Впервые термин прозвучал на Selenium Conf в 2018 году, и до сих пор многие в индустрии считают его просто эффектной аббревиатурой: мол, QA и так входит в DevOps, не стоит приклеивать «Ops» к каждому слову. Мы не спорим о названиях – нам важнее суть. 

Если коротко, речь о трёх вещах.

• Во‑первых, проверки становятся частью пайплайна – никакой работы «в голове» тестировщика и никаких Excel‑файлов «Регресс_final_v3».
• Во‑вторых, у QA есть чёткие права и обязанности в конвейере: доступ к сборкам, логам и метрикам продакшена, а вместе с тем – ответственность за то, чтобы проверки действительно работали.
• В‑третьих, обратная связь приходит за минуты, а не в конце спринта.

Если обобщить, QAOps – это подход, при котором контроль качества встраивается в конвейер CI/CD, а тестирование идёт непрерывно на всех этапах разработки. В отличие от привычной модели, когда QA подключают ближе к финалу, здесь тестировщики, разработчики и DevOps работают как единая команда. Основа подхода – автоматизированные проверки, мониторинг и быстрые циклы обратной связи.

Чем QAOps отличается от DevOps?

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

Почему мы решили написать про внедрение QAOps?

Всё началось с цифры, которая никак не выходила из головы. Faros AI сняли данные с 22 000 разработчиков из 4 000 команд. Картина получилась показательная: там, где активно применяли ИИ‑инструменты, росло число мерджащихся пул‑реквестов. При этом медианное время ревью подскакивало на 441%, а доля PR, которая уходила в мастер без проверки, увеличилась на 31%.

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

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

Почему QAOps стал особенно важен в эпоху ИИ?

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

• По данным отчёта DORA за 2025 год (опрошено около 5 000 респондентов), ИИ используют 90% разработчиков. Впервые за всё время наблюдений внедрение ИИ положительно связано с пропускной способностью поставки – и по‑прежнему отрицательно со стабильностью. Авторы отчёта формулируют это прямо: ИИ сильную команду делает сильнее, слабую – делает ещё более хаотичной и малоэффективной.

• Отчёт Cursor о привычках разработчиков (январь 2025 – май 2026) показывает: скорость написания кода выросла вдвое – с 3,6 до 8,6 тысяч строк в неделю. При этом пул‑реквесты стали в 2,5 раза крупнее, а доля PR объёмом от 1 000 строк выросла с 8% до 14%.

• Анализ GitClear по 211 миллионам изменённых строк выявил тревожную динамику: доля «перемещённых» строк (то есть признаков рефакторинга) упала с примерно 25% в 2021 году до менее 10% в 2024‑м. При этом доля копипасты выросла с 8,3 % до 12,3%. 2024 год стал первым, когда копипасты в коммитах стало больше, чем рефакторинга, а количество дублирующихся блоков увеличилось в восемь раз.

• С точки зрения безопасности картина тоже непростая. По данным Veracode, при проверке более 100 моделей на 80 задачах в 45% случаев в код попадала уязвимость из OWASP Top 10. Атаки типа XSS не блокировались в 86% случаев. Самое важное: модели лучше справляются с синтаксисом, но не становятся безопаснее. Это не временная трудность, а системная проблема.

• А согласно Stack Overflow, 66% тратят на отладку ИИ‑кода больше времени, чем на его написание, и лишь 3% по‑настоящему доверяют полученному результату.

Теперь посмотрим на российскую практику, чтобы картина была полной. 

В «Т‑Технологиях» 58% инженеров пишут код с помощью ИИ, но доверяют ему лишь 11%. При этом 64% отмечают рост личной продуктивности – однако общий процесс разработки от этого заметно не ускоряется. В самом Т‑Банке ИИ‑инструментами регулярно пользуются более 85% разработчиков – это свыше 12 000 человек. 

По данным ICT.Moscow, 76% опрошенных разработчиков уже применяли «вайб‑кодинг» в рабочих задачах. 

Если сложить всё вместе: кода стало вдвое больше, пул‑реквесты – крупнее, доверия к коду – меньше, а возможности проверки остались на прежнем уровне. Именно это и создаёт разрыв между QA и DevOps – только теперь он стал гораздо заметнее из‑за ускорения процессов.

Отдельно про ИИ-код: почему старый регресс его не ловит?

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

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

Ссылка на интерактивный HTML придёт вам на почту. Чтобы получить его бесплатно, нажмите на кнопку, заполните форму и мы отправим вам его.

Шесть барьеров, которые мешают внедрить QAOps

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

Первый барьер: QA не пускают в пайплайн

Симптом простой: тестировщик пишет девопсу «перезапусти джобу, пожалуйста» и полдня ждёт. Или не может приступить к работе, потому что нет доступа к артефактам.

Что делать:

• выдать QA базовые права – запускать и перезапускать пайплайн, читать логи, видеть артефакты и дашборды прода. Это решается одним тикетом, не нужно начинать с масштабных разговоров о доверии;
• добавить в Definition of Done пункт «проверки в пайплайне» и обязательно назначить ответственного: без владельца любой пункт остаётся просто пожеланием;
• ещё один шаг – вовлечь QA в груминг и дизайн‑ревью. Да, это не самая захватывающая часть работы, но профилактика дефектов по‑прежнему остаётся самым дешёвым и эффективным способом держать качество на уровне.

Второй барьер: автотесты есть, но им не доверяют

Это один из самых опасных случаев: красный билд перестают воспринимать как сигнал проблемы и просто перезапускают. В итоге теряется сам смысл автоматических проверок (как из басни Эзопа про мальчика, который кричал «Волк!»).

Что делать:

• измерить flaky rate – долю тестов, которые дают разный результат на одном и том же коммите. Цель – меньше 1%. На практике у многих команд этот показатель держится на уровне 5–15%, хотя почти никто его не отслеживает. Без цифры любые разговоры о доверии к тестам превращаются в спор о вкусах;
• ввести карантин: нестабильный тест автоматически убирают из блокирующего набора, заводят на него баг с чётким SLA. Если за две недели не починили – тест удаляют. Это болезненно, но эффективно;
• запретить практику «перезапусти, оно само пройдёт». Это вопрос дисциплины команды, а не технических настроек.

Третий барьер: прогон тестов длится четыре часа

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

Что делать:

• разделить проверки на три эшелона. На этапе PR‑гейта должны проходить только быстрые проверки: юнит‑тесты, контракты, линтеры, SAST – всё, что укладывается в 10 минут. На этапе merge‑гейта – ключевые интеграционные тесты и smoke‑проверки, укладывающиеся в 30 минут. Всё остальное, включая UI и нагрузочные тесты, уходит в ночной прогон; 
• шардировать и параллелить: чаще всего это даёт больший эффект, чем тонкая оптимизация самих тестов, и обходится дешевле;
• гонять то, что относится к изменённым модулям (risk-based selection), а не весь набор на каждый чих;
• стоит вернуть классическую пирамиду тестирования: если 70% тестов идут через UI, никакая инфраструктура не спасёт от роста времени прогона и числа нестабильных результатов.

Четвёртый барьер: нет подходящих окружений и данных

Классика жанра: один стенд, на нём три команды и вечное «Вась, не деплойся, я тестирую».

Что делать:

• внедрять эфемерные окружения под каждый PR: подойдёт docker compose или namespace в Kubernetes. Даже неидеальная реализация сильно меняет ситуацию;
• тестовые данные как код: сиды в репозитории, генерация, обезличивание продовых. Не «выгружаем дамп руками раз в квартал» – это ещё и 152-ФЗ, если что;
• контрактные тесты вместо ожидания: они позволяют проверять взаимодействие сервисов без ожидания, пока соседняя команда поднимет интеграционный стенд.

Пятый барьер: отсутствие метрик, а значит, и разговора с бизнесом

Пока нет цифр, просьбы выделить ресурсы на «улучшение качества» звучат как эмоции, а не как обоснованные аргументы.

Метрики QAOps: что действительно стоит измерять: 

• метрики DORA плюс rework rate – долю незапланированных деплоев ради отладки пользовательских проблем. DORA добавила её как пятую метрику именно потому, что в эпоху ИИ код производится быстрее, чем проверяется;
• Escaped defects: сколько дефектов нашли пользователи, а не вы;
• время от коммита до сигнала;
• Flaky rate.

Всё. Не надо сорока метрик. Достаточно этого набора, которые CTO реально смотрит раз в две недели.

Шестой барьер (бонусный): нехватка зрелых инженерных практик

Тут врать не буду: это самое дорогое. Инженер, который умеет одновременно в тест-дизайн, в пайплайн и в Kubernetes, – редкий зверь и стоит соответственно. Вариантов три: растить внутри (9–12 месяцев, с риском, что уйдёт, как только вырастет), нанимать (дорого и долго) или взять экспертизу на аутсорсе на время постановки процесса.

Снизит ли QAOps затраты и ускорит ли релизы?

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

Зато позже появляются реальные выгоды. 

1. Снижается стоимость дефектов: чем раньше находят ошибку, тем дешевле её исправить. Не будем опираться на расхожую фразу про «в 100 раз дороже в проде» – у неё спорная методология. Лучше посчитать на своих данных: возьмите 10 последних инцидентов в проде и сложите часы всех, кто в них участвовал – от разработчиков до поддержки и менеджмента. Обычно сумма выходит внушительная.
2. Падает rework rate – доля незапланированных доработок. По сути, это прямые потери: люди вынуждены делать одну и ту же работу дважды. Просто раньше эти траты не считали отдельно.
3. Сокращается время ожидания. В большинстве команд задача реально находится «в работе» всего несколько часов в неделю, а остальное время уходит на ожидание стенда, ревью, регресса или релизного окна. QAOps не заставляет людей работать быстрее – он убирает простои. Именно отсюда и берётся эффект «в два раза быстрее», а не из того, что разработчики начнут печатать код стремительнее.
4. Наконец, снижается цена «героических» решений: ночных регрессий перед релизом, подхода «выкатим и посмотрим», а заодно – выгорания и текучки кадров. Всё это тоже стоит денег, просто они прячутся в другой статье бюджета – например, в расходах на подбор персонала.

И сразу скажем, когда с QAOps заигрывать не стоит. Если релизы выходят раз в квартал по жёсткому регламенту и изменить это нельзя, то ускорять конвейер бессмысленно – он упрётся в бумажные процессы. Если продукт создан для проверки гипотезы и через пару месяцев его планируют закрыть, то тут проще действовать проще и прямолинейнее. И ещё один важный момент: если у вас пока нет CI, сначала стоит внедрить его. Это база, без которой дальше двигаться сложно.

Можно ли внедрять QAOps с аутсорс-подрядчиком по QA?

Нас часто спрашивают об этом – и почти всегда с негласным ожиданием услышать «да, всё получится». Будем честны: получится, но далеко не в любой ситуации и не с любым подрядчиком.

Вот на что стоит обратить внимание до подписания договора. 

1. У внешней команды должен быть прямой доступ к вашему пайплайну – не нужно обмениваться билдами по почте. 
2. Её инженеры должны быть в ваших рабочих каналах и участвовать в стендапах, а не ограничиваться еженедельными отчётами. 
3. С вашей стороны обязательно должен быть ответственный за качество – нельзя просто переложить эту задачу на подрядчика. 
4. Договор стоит строить вокруг конкретных результатов и измеримых метрик, а не количества отработанных часов. 
5. Заранее продумайте, что и когда останется в вашей команде после ухода подрядчика – нужен понятный план передачи знаний и процессов. 
6. И, конечно, важно чётко зафиксировать модель доступа к данным и подписать NDA. Для финтеха и госсектора тут есть дополнительные нюансы: стоит учитывать, из каких регионов работает команда и как организован доступ к защищённым контурам.

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

А ваша команда готова к внедрению QAOps?

Эффективность этого подхода напрямую зависит от зрелости процессов: наличия CI/CD, уровня автоматизации тестирования, качества инженерных практик и культуры взаимодействия между разработкой, QA и DevOps. Если базовые процессы ещё не выстроены, то попытка внедрить QAOps может лишь добавить сложности, а не ускорить релизы.

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

Лестница зрелости команды разработки

Короткий тест для оценки готовности процессов к QAOps

Двенадцать вопросов, отвечать честно (0 – нет, 1 – частично, 2 – да).

1.  Каждый коммит автоматически собирается и прогоняет тесты.

2.  Красный билд блокирует мёрж технически, а не по договорённости.

3.  Блокирующий набор проходит меньше чем за 15 минут.

4.  Flaky rate известен в цифрах и меньше 1%.

5.  Тесты лежат в том же репозитории, что и код, и ревьюятся так же, как код.

6.  Окружение и тестовые данные поднимаются автоматически.

7.  У QA есть доступ к пайплайну, логам и метрикам прода.

8.  QA участвует в обсуждении требований до того, как написан код.

9.  В пайплайне есть SAST и проверка зависимостей. Если у вас ИИ-код – это не опция.

10. Вы знаете свои метрики DORA за последний квартал.

11.  Вы знаете, сколько дефектов за квартал нашли пользователи, а не вы.

12. Откат релиза занимает меньше 15 минут, и это проверено на учениях, а не в теории.

Считаем сумму:

17–24 балла. У вас уже QAOps, вопрос в шлифовке. Идите оптимизировать время обратной связи и покрытие рисков, а не читать статьи вроде этой.

9–16 баллов. Самое подходящее состояние. Фундамент есть, эффект будет максимальным. Большинство команд, которые я смотрел, живут здесь.

0–8 баллов. Про QAOps говорить рано. Чините CI и стабильность тестов, вернётесь через квартал. Внедрение поверх этого фундамента только ускорит развал – ровно по DORA.

Вместо вывода

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

Мы в «Лаборатории Качества» уже более 17 лет помогаем выстраивать такие процессы. За это время реализовали более 530 проектов по тестированию, работаем в 40 регионах России и СНГ. Мы сначала проводим аудит и показываем реальную картину по вашему проекту, затем настраиваем QAOps под ваш пайплайн и передаём экспертизу вашей команде – чтобы дальше вы работали самостоятельно.

Если хотите сначала просто разобраться, есть ли у вас эта проблема и насколько она серьёзная, – предлагаем бесплатную стратегическую консультацию.