Что такое SAFe?
Scaled Agile Framework (SAFe) — это набор паттернов для внедрения agile-практик в масштабе предприятия. В то время как Scrum хорошо работает для одной команды из 5-9 человек, SAFe координирует работу десятков или даже сотен команд, создающих единый продукт или решение.
SAFe — наиболее распространённый фреймворк масштабирования, используемый примерно 53% организаций, практикующих масштабный agile. Как QA-инженер, вы можете столкнуться с SAFe в средних и крупных компаниях, особенно в регулируемых отраслях — финансы, здравоохранение, государственный сектор.
Четыре Уровня SAFe
SAFe работает на четырёх уровнях, каждый с отдельными обязанностями QA:
Стратегические темы, финансирование] --> LS[Уровень Large Solution
Координация нескольких ART] LS --> PR[Уровень Программы - ART
5-12 команд, согласованные по целям PI] PR --> T[Уровень Команды
Отдельные Scrum/Kanban команды] style P fill:#7B1FA2,color:#fff style LS fill:#1565C0,color:#fff style PR fill:#2E7D32,color:#fff style T fill:#E65100,color:#fff
Уровень Команды
Здесь большинство QA-инженеров проводят основное время. На уровне команды вы работаете как член agile-команды (Scrum или Kanban) в составе Agile Release Train (ART).
Активности QA на уровне команды:
- Написание и выполнение тест-кейсов для user stories
- Участие в церемониях спринта
- Функциональное, регрессионное и исследовательское тестирование
- Автоматизация тест-кейсов для CI/CD-пайплайна
- Обеспечение включения критериев качества в Definition of Done команды
Уровень Программы (Agile Release Train)
Agile Release Train (ART) — это команда agile-команд (обычно 5-12 команд, 50-125 человек), которые планируют, берут обязательства и поставляют вместе. ART работает на фиксированной каденции, называемой Program Increment (PI), обычно 8-12 недель (4-6 спринтов).
Активности QA на уровне программы:
- Участие в PI Planning для выявления зависимостей тестирования между командами
- Системное интеграционное тестирование на границах команд
- End-to-end тестирование фич, охватывающих несколько команд
- Вклад в System Demo (каждые 2 недели)
- Работа с System Team над общей инфраструктурой тестирования
Уровень Large Solution
Когда решение требует нескольких ART, уровень Large Solution координирует их. Этот уровень актуален для сложных продуктов — авиационные системы, банковские платформы или масштабные SaaS-продукты.
Активности QA на уровне Large Solution:
- Интеграционное тестирование на уровне решения между ART
- Тестирование производительности и масштабируемости интегрированного решения
- Тестирование соответствия нормативным требованиям
- Координация тестовых окружений между ART
Уровень Portfolio
Уровень Portfolio связан со стратегией, финансированием инвестиций и управлением. Участие QA здесь косвенное, но важное.
Влияние QA на уровне Portfolio:
- Метрики качества информируют инвестиционные решения
- Инфраструктура тестирования финансируется как enabler
- Стандарты качества определяются как часть управления
- Оценки рисков влияют на приоритизацию портфеля
PI Planning: Перспектива QA
PI Planning — самое важное событие в SAFe. Это двухдневное мероприятие, где все команды ART собираются для планирования следующего Program Increment.
Перед PI Planning
Подготовка QA:
- Просмотр предстоящих фич и их критериев приёмки
- Выявление потенциальных зависимостей тестирования между командами
- Оценка потребностей в тестовых окружениях для PI
- Оценка трудозатрат на тестирование фич высокого уровня
- Подготовка списка рисков и проблем тестирования
Во время PI Planning
День 1:
- Презентация бизнес-контекста и видения — понять, что строит ART
- Брифинг по архитектуре — выявить технические риски, влияющие на тестирование
- Сессии команд — планирование активностей тестирования для каждого спринта PI
- Черновики целей PI — включить цели, связанные с качеством
День 2:
- Продолжение сессий команд — финализация планов тестирования
- Выявление и разрешение зависимостей между командами (многие связаны с тестированием)
- Голосование о уверенности — честная оценка достижимости плана с учётом ёмкости тестирования
- Корректировка плана — согласование scope при недостатке ресурсов тестирования
Активности PI Planning Специфичные для QA
| Активность | Когда | Цель |
|---|---|---|
| Маппинг зависимостей | День 1 | Определить, какие фичи требуют кросс-командного тестирования |
| Планирование окружений | День 1-2 | Обеспечить доступность окружений для интеграционного тестирования |
| Идентификация рисков | День 1 | Отметить фичи с высоким риском тестирования |
| Планирование ёмкости | День 2 | Оценить пропускную способность тестирования по спринтам |
| Голосование о уверенности | День 2 | Честная оценка выполнимости плана |
Ключевой момент: Если вы QA-инженер и вас не приглашают на PI Planning, немедленно эскалируйте это. Вклад QA при планировании предотвращает дорогостоящие узкие места при исполнении.
System Team
SAFe вводит концепцию, которой нет в Scrum одной команды: System Team. Это специализированная команда, ответственная за:
- Создание и поддержку общих тестовых окружений
- Запуск системных интеграционных тестов
- Поддержку end-to-end тестирования между командами
- Управление CI/CD-пайплайнами на уровне ART
- Выполнение нефункционального тестирования (производительность, безопасность, надёжность)
Как QA-инженер, вы можете работать в System Team или тесно сотрудничать с ней. Понимание её роли помогает понять, где заканчивается тестирование вашей команды и начинается системное тестирование.
Built-in Quality
Built-in Quality — одна из четырёх базовых ценностей SAFe. Это означает, что качество — не то, что происходит в конце, оно встроено на каждом уровне:
Качество Кода
- Test-Driven Development (TDD)
- Парное программирование и code reviews
- Непрерывная интеграция с автоматизированными тестами
- Статический анализ кода
Качество Дизайна
- Эмерджентный дизайн с целенаправленной архитектурой
- Domain-Driven Design
- Ревью дизайна с тестируемостью как критерием
Качество Системы
- Непрерывная интеграция на уровне системы
- Автоматизированное регрессионное тестирование
- Нефункциональное тестирование (производительность, безопасность)
- Feature toggles для безопасного деплоя
Качество Релиза
- Возможность релиза по требованию
- Canary-релизы и blue-green deployments
- Автоматизированные пайплайны деплоя
- Мониторинг и алертинг в продакшене
Как QA Обеспечивает Built-in Quality
| Практика | Вклад QA |
|---|---|
| TDD | Ревью качества тестов, обеспечение покрытия граничных случаев |
| CI/CD | Поддержка автоматизированных тестовых наборов, мониторинг надёжности тестов |
| Code reviews | Ревью тестового кода, проверка тестируемости продакшен-кода |
| Архитектура | Отстаивание тестируемых архитектурных решений |
| Стандарты | Определение и поддержание стандартов качества между командами |
Итерация Innovation and Planning (IP)
Каждый PI включает итерацию Innovation and Planning (IP) — выделенный спринт для:
- PI Planning для следующего инкремента
- Инноваций и исследований
- Улучшения инфраструктуры и инструментов
- Сокращения технического долга
- Улучшения автоматизации тестирования
Для QA итерация IP бесценна. Используйте её для:
- Рефакторинга кода автоматизации тестов
- Улучшения инфраструктуры тестирования
- Исследования новых инструментов тестирования
- Исправления нестабильных тестов
- Документирования стандартов и паттернов тестирования
Упражнение: Определить Активности QA на Каждом Уровне SAFe
Вы — QA Lead в компании финансовых услуг, внедрившей SAFe. В компании:
- 3 ART работают над банковской платформой
- В каждом ART 8 команд
- В каждой команде 1-2 QA-инженера
- System Team, общий для всех ART
Новое нормативное требование обязывает все клиентские транзакции быть зашифрованными end-to-end и аудируемыми. Этот feature охватывает все 3 ART.
Ваша задача:
Для каждого уровня SAFe определите конкретные активности QA, необходимые для поставки этого feature:
- Уровень команды: Что делает QA-инженер каждой команды?
- Уровень программы (ART): Какое кросс-командное тестирование необходимо внутри каждого ART?
- Уровень Large Solution: Какое тестирование координируется между всеми 3 ART?
- Уровень Portfolio: Какое управление качеством необходимо?
Также ответьте: Где вы видите наибольший риск тестирования и как бы вы его снизили?
Подсказка
Учтите следующие аспекты:
- Шифрование требует как позитивного тестирования (данные зашифрованы), так и негативного (незашифрованные данные отклоняются)
- «Аудируемый» означает наличие логов — проверьте, что логи полные и защищённые от подделки
- Регуляторные требования часто приходят со специфическими стандартами compliance-тестирования
- Кросс-ART интеграционное тестирование требует общих окружений
- Тестирование производительности критически важно — шифрование добавляет задержку
Пример решения
Активности QA по Уровням SAFe
1. Уровень команды:
QA-инженер каждой команды отвечает за:
- Тестирование корректной реализации шифрования компонентом команды
- Верификацию генерации аудит-логов для транзакций компонента
- Тестирование обработки ошибок при сбое шифрования
- Обеспечение обратной совместимости с незашифрованными данными при миграции
- Написание автоматизированных тестов шифрования в CI/CD-пайплайне
- Негативное тестирование: проверка отклонения незашифрованных транзакций
2. Уровень программы (ART):
Кросс-командные активности QA внутри каждого ART:
- End-to-end тестирование транзакций между командами — проверка сохранения шифрования от начала до конца
- Интеграционное тестирование агрегации аудит-логов — логи всех команд должны быть согласованными и полными
- Тестирование производительности зашифрованных транзакций — измерение влияния на задержку
- Тестирование безопасности на уровне ART — попытки перехватить или расшифровать данные между компонентами
- Подготовка System Demo — демонстрация работы шифрования между компонентами всех команд
- Настройка общего тестового окружения для зашифрованного обмена
3. Уровень Large Solution:
Кросс-ART активности QA:
- Интеграционное тестирование на уровне решения — проверка работы зашифрованных транзакций между всеми 3 ART
- Верификация end-to-end аудит-трейла — транзакция, затрагивающая все 3 ART, должна иметь полный непрерывный лог
- Compliance-тестирование по нормативным стандартам (например, PCI-DSS, SOX)
- Кросс-ART тестирование производительности — измерение полной задержки системы с включённым шифрованием
- Тестирование аварийного восстановления — проверка сохранности аудит-логов при отказе
- Тестирование на проникновение интегрированного решения
4. Уровень Portfolio:
Активности управления качеством:
- Определение стандартов качества шифрования и аудита для всех ART
- Финансирование общих инструментов и инфраструктуры тестирования безопасности
- Установление каденции compliance-тестирования (например, ежеквартальные аудиты безопасности)
- Создание реестра рисков для feature шифрования на уровне портфеля
- Определение метрик для измерения compliance (например, % зашифрованных транзакций)
Наибольший риск:
Кросс-ART интеграционное тестирование несёт наибольший риск, потому что:
- Три ART должны согласовать протоколы шифрования и управление ключами
- Аудит-логи должны быть согласованными между разными реализациями ART
- Деградация производительности накапливается между ART
- Тестирование требует общего окружения, зеркалирующего продакшен
Снижение рисков:
- Установить общий стандарт шифрования и тестовый набор до начала разработки
- Создать выделенное окружение интеграционного тестирования в начале PI
- Назначить кросс-ART координатора QA для управления интеграционным тестированием
- Проводить инкрементальное интеграционное тестирование (сначала 2 ART, потом все 3)
- Автоматизировать проверки compliance для непрерывного выполнения
Роли SAFe Релевантные для QA
Release Train Engineer (RTE)
RTE — это главный Scrum Master ART. Он фасилитирует PI Planning и координирует кросс-командные активности. QA работает с RTE для:
- Озвучивания impediments тестирования, затрагивающих несколько команд
- Координации расписания тестовых окружений
- Коммуникации рисков качества на уровне ART
System Architect
System Architect определяет техническую архитектуру решения ART. QA сотрудничает для:
- Обеспечения поддержки тестируемости в архитектуре
- Выявления потребностей нефункционального тестирования
- Планирования тестирования производительности и масштабируемости
Product Management
Product Management определяет фичи и приоритеты ART. QA работает с Product Management для:
- Уточнения критериев приёмки на уровне фич
- Коммуникации компромиссов качества (scope vs. качество)
- Предоставления данных о качестве для информирования приоритизации фич
Профессиональные Советы для QA в SAFe
Возьмите на себя координацию кросс-командного тестирования. В SAFe наибольшие риски качества — в точках интеграции между командами. Если никто не координирует кросс-командное тестирование явно, возьмите инициативу.
Используйте итерацию IP с умом. Это ваш шанс улучшить инфраструктуру тестирования, сократить тестовый долг и поэкспериментировать с новыми инструментами. Не позволяйте ей стать ещё одним спринтом поставки.
Стройте отношения с QA-инженерами других команд. В ART с 8 командами знание QA-инженера в каждой команде делает координацию тестирования гораздо более гладкой, чем работа через менеджеров.
Отстаивайте паритет тестовых окружений. Одна из главных проблем SAFe — общие тестовые окружения. Добивайтесь окружений, максимально приближенных к продакшену, с чётким расписанием.
Измеряйте качество на каждом уровне. Отслеживайте процент сбежавших дефектов на уровне команды, ART и решения. Эти данные помогают обосновать инвестиции в практики качества на PI Planning и ревью портфеля.