Тестирование и QA-процессы — это совокупность организационных и технических мер, направленных на обеспечение заданного уровня качества ПО на всех стадиях его жизненного цикла. В 2026 году акцент сместился на измеримость, автоматизацию и compliance: компании внедряют сквозные метрики качества, переводят до 70% ручных проверок в автотесты и проходят аттестацию по требованиям ФСТЭК. Ключевые цифры: средний показатель покрытия кода автотестами в коммерческой разработке вырос с 35% (2022) до 58% (2026), а время устранения критических дефектов сократилось до 4,5 часов при настроенном CI/CD-пайплайне. Для ИТ-руководителя это означает, что без формализованных QA-процессов невозможно гарантировать стабильность продукта и соответствие регуляторным нормам.
Материал ориентирован на технических директоров, руководителей разработки и владельцев продуктов, которые хотят построить или модернизировать систему обеспечения качества с учётом российского регулирования. Ниже — разбор метрик, этапов автоматизации, нагрузочного тестирования и обязательных активностей по безопасности, подкреплённый практическими примерами и чек-листами.
Что изменилось в подходах к QA к 2026 году
Курс на импортозамещение и ужесточение требований к защите информации заставили компании пересмотреть QA-цикл. Многие организации мигрировали с западных ALM-систем на российские платформы, что потребовало пересборки тестовой инфраструктуры. Дополнительным драйвером стало включение большинства значимых ИТ-проектов в реестр отечественного ПО Минцифры: для аттестации нужны документированные свидетельства тестирования и приёмочных испытаний.
Ручное тестирование уступило место гибридным моделям. Если в 2020 году лишь треть проверок была автоматизирована, то к 2026-му доля автоматизации в среднем проекте достигла 55–70%. Одновременно произошёл сдвиг от реактивного поиска дефектов к предиктивному качеству: команды анализируют исторические данные и предотвращают ошибки на этапе проектирования.
Ниже — сравнение ключевых аспектов QA-процессов в 2020 и 2026 годах.
| Аспект | 2020 | 2026 |
|---|---|---|
| Доля автоматизации | <30% | 55–70% |
| Инструменты | Проприетарные западные (Jira, TestRail) | Российские и Open Source (Allure TestOps, Katalon Studio RS) |
| Безопасность | По остаточному принципу | Встроена в CI/CD с ранних этапов |
| Регулирование | ГОСТ 19, добровольное | Обязательное для госИС и КИИ, ФСТЭК |
| Метрики | Интуитивные, постфактум | Предиктивные, на основе данных |
Метрики качества ПО: что измерять и зачем
Метрики превращают QA из чёрного ящика в измеримый процесс. Без цифр невозможно оценить динамику, спрогнозировать стабильность релиза или обосновать инвестиции в инфраструктуру. Выбор метрик зависит от контекста: для стартапа важна скорость обнаружения дефектов, для разработчика госИС — полнота покрытия требований безопасности.
Основные группы метрик:
-
Плотность дефектов: число дефектов на 1000 строк кода или на модуль. Ориентир — не более 2–3 критических дефекта на 1000 строк.
-
Покрытие кода тестами: процент строк, затронутых автотестами. Целевой минимум — 80% для модульных тестов.
-
Время восстановления (MTTR): от обнаружения инцидента до закрытия. В высоконагруженных системах стремятся к <2 часов.
-
Распределение дефектов по критичности: доля блокирующих и критических дефектов не должна превышать 10% от общего числа.
-
Утечка дефектов: количество ошибок, найденных пользователями после релиза. Цель — не более 1–2 на 1000 пользователей в месяц.
Для наглядности — карта метрик по ролям:
| Роль | Ключевые метрики | Цель |
|---|---|---|
| Владелец продукта | Утечка дефектов, NPS, время вывода фичи | Минимизация пользовательских инцидентов |
| Руководитель разработки | Покрытие кода, MTTR, время цикла | Предсказуемость релизов |
| QA-инженер | Плотность дефектов, процент автоматизации, стабильность тестов | Эффективность тестового набора |
| DevOps/безопасник | Число уязвимостей на сборку, время исправления уязвимости | Безопасность пайплайна |
Автоматизация тестирования: с чего начать и как развивать
Автоматизация ускоряет обратную связь, снижает влияние человеческого фактора и позволяет чаще выпускать релизы. Ключевой принцип — тестовая пирамида: много быстрых модульных тестов, средний слой интеграционных проверок и минимум медленных сквозных сценариев.
Дорожная карта автоматизации:
-
Оцените текущее состояние: какие тесты уже есть, какие сценарии критичны.
-
Выберите стек инструментов, ориентируясь на реестр отечественного ПО. Для веб-приложений подойдёт Katalon Studio RS, для отчётности — Allure TestOps.
-
Разработайте каркас автотестов и внедрите практику code review тестового кода.
-
Интегрируйте автотесты в CI/CD-пайплайн: GitFlic CI/CD или «Р7-Команда».
-
Настройте дашборд с историей прогонов, алертами о падениях и трендами покрытия.
Особое внимание — к выбору типа автоматизации. Модульные тесты пишутся разработчиками параллельно с кодом, интеграционные проверяют контракты API, а сквозные эмулируют пользовательские сценарии. Золотое правило: автоматизируйте только стабильные, повторяемые проверки.
Нагрузочное тестирование в российских реалиях
Нагрузочное тестирование уже не опционально: для систем с государственными сервисами, учётных конфигураций «1С» и высоконагруженных B2C-порталов оно стало обязательным этапом приёмки. Падение портала Госуслуг в пиковый период — яркий пример, почему 99-й процентиль времени отклика должен держаться ниже 2 секунд.
Ключевые метрики:
-
RPS (запросов в секунду) — показывает пропускную способность.
-
Время отклика (latency) — p50, p95, p99.
-
Утилизация ресурсов — CPU, память, диск.
-
Количество ошибок — доля ответов с кодом 5xx.
Инструментарий: в условиях импортозамещения используют JMeter (развёрнутый на отечественной инфраструктуре) и Яндекс.Танк. Эталонный сценарий включает профилирование узких мест, генерацию ступенчатой нагрузки и анализ метрик на каждом уровне стека. Результаты фиксируют в протоколе нагрузочного тестирования, который затем становится частью комплекта документации по ГОСТ 19.
Тестирование безопасности: требования ФСТЭК и ГОСТ Р 56939
ГОСТ Р 56939 описывает процессы безопасной разработки, а приказы ФСТЭК конкретизируют обязательный состав проверок для государственных информационных систем и объектов КИИ. QA-цикл должен включать:
-
Статический анализ кода (SAST) на этапе коммита.
-
Динамический анализ (DAST) на тестовом окружении.
-
Проверку зависимостей на известные уязвимости (SCA).
-
Фаззинг для выявления скрытых дефектов в протоколах.
-
Ручное тестирование на проникновение не реже одного раза в квартал.
Результаты оформляются тестовым протоколом с указанием идентификатора уязвимости, критичности и рекомендаций по устранению. Для прохождения аттестации во ФСТЭК заказчик обязан предоставить полный пакет свидетельств: план тестирования безопасности, журнал дефектов, отчёты инструментальных сканеров и заключение о соответствии ГОСТ Р 56939-2016.
Документирование QA-процессов: ГОСТ 19 и ЕСПД
ГОСТ 19 (Единая система программной документации) устанавливает состав и правила оформления документов на всех этапах разработки. Применительно к QA это означает:
-
План тестирования (по форме ПМИ) — определяет объекты, стратегию, критерии приёмки.
-
Спецификация тест-кейсов — набор сценариев с идентификаторами, предусловиями и ожидаемыми результатами.
-
Журнал тестирования — хронология прогонов, обнаруженных дефектов и статусов.
-
Отчёт о тестировании — сводка результатов, оценка качества и решение о выпуске.
Даже если команда работает по Agile, пакет документов по ГОСТ 19 часто требуют при сдаче заказной разработки, особенно в госсекторе. Шаблонное оформление экономят время: создайте репозиторий с шаблонами docs/qa/templates, автоматизируйте генерацию отчётов из Allure или Katalon, а журнал дефектов ведите в TMS с выгрузкой в требуемом формате.
Ниже — минимальный набор документов по фазам:
| Фаза | Документ | Комментарий |
|---|---|---|
| Планирование | План тестирования | Согласовывается до начала разработки |
| Проектирование | Спецификация тест-кейсов | Может дополняться итеративно |
| Выполнение | Журнал тестирования | Фиксируется ежедневно |
| Завершение | Отчёт о тестировании | Подписывается при приёмке |
Интеграция QA в DevSecOps: пайплайн, инструменты, контроль
Современный QA-цикл не существует изолированно — он встроен в единый конвейер. Типовая структура пайплайна с контрольными точками качества:
-
Статический анализ кода (SAST) при создании Pull Request.
-
Прогон модульных тестов.
-
Сборка и интеграционное тестирование в изолированном окружении.
-
Сканирование контейнеров на уязвимости.
-
Развёртывание на staging и запуск сквозных автотестов.
-
Нагрузочное тестирование (при необходимости).
-
Ручное исследовательское тестирование критических сценариев.
-
Анализ метрик и «зелёный» билд для деплоя.
Метрики пайплайна (DORA-метрики) дополняют картину: частота деплоев, время цикла, доля отказов и MTTR. В российских реалиях в качестве CI/CD-сервера часто выбирают GitFlic CI/CD, в качестве оркестратора — «Р7-Команда». Контроль безопасности встраивают через обязательные шаги, падение которых блокирует выпуск.
Типичные ошибки внедрения метрик и автоматизации
Даже продуманная программа может провалиться из-за типовых просчётов. Вот самые частые:
-
Покрытие ради покрытия: команда гонится за процентом, пишет хрупкие тесты, не проверяющие логику.
-
Автоматизация всего подряд: сценарии, меняющиеся каждый спринт, лучше оставить ручными.
-
Метрики без контекста: использовать число открытых дефектов как KPI без учёта их критичности — гарантия конфликтов.
-
Игнорирование ручного тестирования: исследовательские сессии находят до 30% дефектов, которые не ловят скрипты.
-
Запаздывание с нагрузочными тестами: откладывать их на финальный этап — рисковать обнаружить архитектурную проблему перед самым релизом.
Лучшая страховка — регулярный аудит тестового набора и двусторонняя связь между метриками и реальными инцидентами на проде.
Дорожная карта построения QA-цикла: пошаговый план
Переход к измеримому, автоматизированному и регулируемому QA-циклу удобно вести в четыре этапа:
-
Оценка текущего состояния: инвентаризация тестов, метрик, инструментов. Формулирование цели — например, «снизить утечку дефектов до 0,5 в месяц и пройти аттестацию ФСТЭК за 6 месяцев».
-
Пилот: на одном продукте внедряют стек автоматизации, две-три ключевых метрики и процедуру статического анализа. Длится 2–3 месяца.
-
Масштабирование: распространение практик на остальные команды, подключение нагрузочного тестирования и расширенного набора метрик. Интеграция в CI/CD.
-
Оптимизация: постоянный пересмотр пороговых значений метрик, ротация тестового набора, внедрение практик shift-left. Периодический аудит на соответствие ГОСТ Р 56939 и требованиям ФСТЭК.
При необходимости спроектировать и внедрить такой цикл в вашей компании стоит проконсультироваться со специалистами по автоматизации QA-процессов.