Отличие enterprise QA от продуктового: масштаб, compliance, legacy · 13 мин
🎯 Цель урока

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

Контекст

Enterprise QA существует в среде, где одна система обслуживает тысячи пользователей, десятки бизнес-процессов и интегрирована с десятками других платформ. Ошибка в релизе может остановить начисление заработной платы или закрытие финансового периода. В отличие от продуктового QA, здесь не принято итерировать быстро: каждый релиз проходит через Change Advisory Board и формальное управление изменениями.

  • Enterprise-система обслуживает от сотен до десятков тысяч конкурентных пользователей
  • Legacy-компоненты — COBOL, RPG, мейнфреймы — сосуществуют с современными микросервисами
  • Compliance-требования (SOX, GDPR, ISO 27001) диктуют обязательные контрольные точки в тест-процессе
  • Тест-команды разделены по компетенциям: функциональный QA, performance, security, data quality
  • Бюджеты и ROI тестирования измеряются в миллионах, а не тысячах долларов

Рабочий алгоритм

Чтобы выстроить enterprise QA с нуля или провести аудит существующего, следуйте этому алгоритму.

  • Шаг 1. Составьте карту систем: перечислите все приложения, их критичность для бизнеса и уровень регуляторного контроля
  • Шаг 2. Определите compliance-требования для каждой системы и зафиксируйте обязательные тест-артефакты (evidence пакеты)
  • Шаг 3. Оцените legacy-риски: найдите компоненты без документации и без автотестов, присвойте им приоритет
  • Шаг 4. Разделите команду на стримы с чёткими зонами ответственности и интерфейсами взаимодействия
  • Шаг 5. Установите SLA на каждый тип тестирования: от unit-теста до UAT — с измеримыми критериями выхода
  • Шаг 6. Внедрите governance-ритм: еженедельный quality gate review, ежемесячный metrics report для спонсора

Пример из практики

Крупный производственный холдинг внедрял SAP S/4HANA и столкнулся с тем, что QA-команда работала по продуктовым практикам: короткие спринты, минимальная документация, нет формального UAT. После первого failed go-live (остановились процессы закупок) была проведена ретроспектива.

  • Обнаружено: отсутствовал compliance-пакет для аудиторов — тест-кейсы не были привязаны к требованиям SOX
  • Решение: введён трёхуровневый тест-процесс — SIT, UAT, parallel run с подписанием acceptance report
  • Для legacy-интерфейсов (EDI с поставщиками) выделен отдельный regression stream
  • Через 6 месяцев второй go-live прошёл без critical issues, аудит SOX был пройден с первого раза

Частые ошибки

Enterprise QA-специалисты, пришедшие из продуктовых компаний, регулярно наступают на одни и те же грабли.

  • Ошибка 1. Применять agile-практики без адаптации к корпоративным governance-процессам — спринты не согласуются с CAB-циклами
  • Ошибка 2. Игнорировать legacy-компоненты под предлогом «они и так работают» — именно они падают в самый неподходящий момент
  • Ошибка 3. Отделять тест-процесс от compliance-требований — в итоге evidence-пакет собирается постфактум и содержит пробелы
  • Ошибка 4. Недооценивать время на data setup: в enterprise тестовые данные требуют согласования с несколькими владельцами
  • Ошибка 5. Отсутствие формальных exit criteria — команда не знает, когда тестирование считается завершённым

Самопроверка

1Чем enterprise QA отличается от продуктового с точки зрения governance?
В enterprise каждый релиз проходит через Change Advisory Board с формальным approval, тогда как в продуктовом QA решение о деплое принимает продуктовая команда без внешних контрольных точек.
2Почему legacy-компоненты представляют особый риск в enterprise?
Legacy-компоненты часто не имеют актуальной документации, автотестов и знания о них сосредоточено у одного-двух специалистов. При изменении интеграций или миграции данных они могут отказать неожиданно.
3Что такое compliance-evidence пакет и зачем он нужен?
Это набор тест-артефактов (тест-планы, тест-кейсы, результаты, дефекты, sign-off), который доказывает аудиторам, что тестирование было проведено в соответствии с регуляторными требованиями (например, SOX или GDPR).