Фреймворк Scrum: Взгляд QA
Scrum — наиболее распространённый agile-фреймворк, используемый примерно 66% agile-команд по всему миру. Как QA-инженер, вы почти наверняка будете работать в среде Scrum на каком-то этапе карьеры. Понимание того, как тестирование вписывается в Scrum, не является опциональным — это необходимость.
Этот урок рассматривает Scrum с точки зрения тестировщика: не просто что такое фреймворк, а как вы активно участвуете в каждой церемонии и работе с артефактами.
Роли Scrum и QA
Scrum определяет три роли. Понимание каждой помогает знать, с кем и когда сотрудничать.
Product Owner (PO)
Product Owner управляет product backlog и приоритизирует работу по бизнес-ценности. Как QA-инженер, вы тесно работаете с PO для:
- Уточнения критериев приёмки user stories
- Выявления граничных случаев, которые PO мог не учесть
- Предоставления оценок рисков, влияющих на приоритизацию
- Демонстрации протестированных фич во время Sprint Review
Scrum Master (SM)
Scrum Master фасилитирует процесс и устраняет препятствия. С точки зрения QA, SM помогает когда:
- Тестовые окружения недоступны или нестабильны
- Зависимости между командами блокируют тестирование
- Команде нужно улучшить практики тестирования (поднимается на ретроспективах)
Development Team
В Scrum Development Team является кросс-функциональной. Это означает, что QA-инженеры являются полноценными членами Development Team, а не отдельной группой. Вы разделяете ответственность за поставку готового инкремента каждый спринт.
Ключевой момент: В Scrum нет отдельной «команды QA». Тестировщики встроены в Development Team. Вся команда отвечает за качество.
События Scrum и Активности Тестирования
Scrum определяет пять событий. QA-инженеры участвуют во всех.
Sprint Planning
Длительность: До 8 часов для 4-недельного спринта (пропорционально меньше для более коротких спринтов).
Активности QA во время Sprint Planning:
- Проверка user stories и критериев приёмки
- Оценка трудозатрат на тестирование каждого story
- Определение зависимостей для тестирования (данные, окружения, сторонние сервисы)
- Выделение stories с высоким риском, требующих дополнительного тестирования
- Помощь команде в определении объёма работ, который они могут взять
Совет QA: Если критерии приёмки размытые, задавайте вопросы во время планирования — не за два дня до конца спринта.
Daily Standup
Длительность: Максимум 15 минут.
Вклад QA:
- Отчёт о том, какие stories вы сейчас тестируете
- Озвучивание блокеров (недоступное окружение, отсутствие тестовых данных, неясные требования)
- Информирование о том, какие stories прошли или не прошли тестирование
- Координация с разработчиками по исправлению багов
Антипаттерн, которого следует избегать: Стендап — это не отчёт для Scrum Master. Это встреча синхронизации для команды. Говорите с коллегами, а не с SM.
Sprint Review
Длительность: До 4 часов для 4-недельного спринта.
Активности QA:
- Демонстрация протестированных фич стейкхолдерам
- Представление метрик покрытия тестами и индикаторов качества
- Указание на риски в фичах, которые не были полностью протестированы
- Сбор обратной связи, которая может породить новые тестовые сценарии
Sprint Retrospective
Длительность: До 3 часов для 4-недельного спринта.
Темы QA для обсуждения:
- Узкие места тестирования, замедлившие спринт
- Улучшения качества (возможности автоматизации, стабильность окружений)
- Проблемы взаимодействия между разработчиками и тестировщиками
- Улучшения процесса для следующего спринта
Тестирование на Протяжении Спринта
Распространённое заблуждение — что тестирование происходит только после завершения разработки. В Scrum тестирование — это непрерывная деятельность:
Дни 1-2: Написание тест-кейсов и подготовка тестовых данных, пока разработчики начинают писать код. Уточнение критериев приёмки с PO.
Дни 3-7: Тестирование stories по мере их завершения. Не ждите, пока все stories будут готовы. Тестируйте каждый, как только разработчики отметят его готовым.
Дни 8-9: Запуск регрессионных тестов. Верификация исправлений багов. Исследовательское тестирование интегрированных фич.
День 10: Финальная валидация, обновление тестовой документации, подготовка к Sprint Review.
Definition of Done (DoD)
Definition of Done — это чеклист, которому должен соответствовать каждый элемент product backlog, прежде чем он будет считаться завершённым. Он согласовывается всей командой и применяется к каждому story.
Сильный DoD Включает Критерии Качества
Пример DoD с выделенными элементами, ориентированными на качество:
| Критерий | Категория |
|---|---|
| Код написан и прошёл code review | Разработка |
| Unit-тесты написаны и проходят (≥80% покрытие) | Качество |
| Все критерии приёмки проверены QA | Качество |
| Нет открытых критических багов и багов высокой серьёзности | Качество |
| Исследовательское тестирование проведено | Качество |
| Регрессионные тесты проходят | Качество |
| Фича развёрнута в staging-окружении | Деплой |
| Документация обновлена | Документация |
| Product Owner принял story | Приёмка |
Почему DoD Важен для QA
Без чёткого DoD «готово» означает разные вещи для разных людей. Разработчик может считать story готовым, когда код компилируется. PO может считать его готовым, когда он хорошо выглядит на демо. DoD устраняет эту неоднозначность.
Ваша ответственность как QA: Отстаивайте критерии качества в DoD. Если DoD команды не включает тестирование, он неполный.
User Stories и Критерии Приёмки
В Scrum требования выражаются как user stories с критериями приёмки. Они являются основой ваших тест-кейсов.
Формат user story:
Как [роль пользователя],
Я хочу [действие],
Чтобы [выгода].
Пример критериев приёмки:
Дано: я на странице входа
Когда я ввожу валидные учётные данные
Тогда я должен быть перенаправлен на дашборд
И я должен увидеть приветственное сообщение с моим именем
Улучшение от QA: Для каждого критерия приёмки подумайте и о негативных сценариях:
- Что произойдёт при невалидных учётных данных?
- Что произойдёт при пустых полях?
- Что произойдёт при спецсимволах в имени пользователя?
Эти негативные сценарии должны стать дополнительными тест-кейсами.
Артефакты Scrum и QA
Product Backlog
Приоритизированный список всего, что может потребоваться в продукте. QA вносит вклад:
- Добавляя stories, связанные с тестированием (например, «Настроить инфраструктуру нагрузочного тестирования»)
- Указывая на технический долг, связанный с тестируемостью
- Просматривая предстоящие stories для планирования подхода к тестированию
Sprint Backlog
Набор элементов, выбранных для текущего спринта, плюс план их выполнения. Задачи QA (написание тест-кейсов, выполнение тестов, автоматизация сценариев) должны быть видны в sprint backlog.
Product Increment
Сумма всех завершённых элементов product backlog на конец спринта. Этот инкремент должен соответствовать Definition of Done и быть потенциально готовым к релизу.
Упражнение: Создание Плана Тестирования для Спринта
Вы — QA-инженер в Scrum-команде. Ваша команда работает двухнедельными спринтами. Product Owner выбрал следующие stories для предстоящего спринта:
User Stories:
- US-101: Как пользователь, я хочу сбросить пароль через email, чтобы восстановить доступ к аккаунту (8 story points)
- US-102: Как администратор, я хочу экспортировать данные пользователей в CSV, чтобы анализировать паттерны использования (5 story points)
- US-103: Как пользователь, я хочу получать push-уведомления о новых сообщениях, чтобы оставаться в курсе (13 story points)
- US-104: Как пользователь, я хочу фильтровать результаты поиска по диапазону дат, чтобы быстрее находить релевантный контент (3 story points)
Ваша задача:
Создайте план тестирования для спринта, включающий:
- Подход к тестированию каждого story (какие виды тестирования вы будете проводить)
- Зависимости и предварительные требования для тестирования
- Помесячный график тестирования на 10 дней спринта
- Оценка рисков: какие stories несут наибольший риск и почему
- Ваш вклад в Definition of Done
Подсказка
Учтите следующие факторы при составлении плана:
- Story points указывают на относительную сложность — US-103 (13 поинтов) самый сложный
- Сброс пароля включает тестирование безопасности (не только функциональное)
- Экспорт CSV требует тестирования валидации данных
- Push-уведомления требуют тестирования на нескольких платформах
- Фильтр дат требует тестирования граничных значений
Начните с определения наиболее рискового story и выделите на него больше времени для тестирования.
Пример решения
План Тестирования Спринта
1. Подход к тестированию по Story:
| Story | Виды тестирования |
|---|---|
| US-101 (Сброс пароля) | Функциональное, безопасности, интеграция email, негативное, кросс-браузерное |
| US-102 (Экспорт CSV) | Функциональное, валидация данных, производительность (большие наборы данных), проверка формата |
| US-103 (Push-уведомления) | Функциональное, кросс-платформенное (iOS/Android/Web), тайминг, офлайн-сценарии |
| US-104 (Фильтр дат) | Функциональное, граничные значения, UI/UX, производительность с большими наборами результатов |
2. Зависимости:
- US-101: Настройка тестового email-сервера, тестовые аккаунты с известными учётными данными
- US-102: Тестовый набор данных с 10K+ записями для тестирования производительности
- US-103: Тестовые устройства (iOS и Android), учётные данные сервиса push-уведомлений
- US-104: База данных с записями, охватывающими различные диапазоны дат
3. Ежедневный график:
| День | Активность |
|---|---|
| 1 | Написать тест-кейсы для US-104 (самый простой, скорее всего готов первым) и US-101 |
| 2 | Написать тест-кейсы для US-102 и US-103. Подготовить тестовые данные. |
| 3-4 | Тестирование US-104 (ожидается готовность разработки к дню 3). Начать тестирование US-101. |
| 5-6 | Завершить тестирование US-101. Начать тестирование US-102. |
| 7-8 | Тестирование US-103 (сложный, ожидается готовность разработки к дню 7). Кросс-платформенное тестирование. |
| 9 | Регрессионное тестирование. Верификация багов. Исследовательское тестирование интегрированных фич. |
| 10 | Финальная валидация. Обновление тестовой документации. Подготовка демо Sprint Review. |
4. Оценка рисков:
| Story | Уровень риска | Причина |
|---|---|---|
| US-103 | ВЫСОКИЙ | Самый сложный (13 pts), кросс-платформенный, зависимость от внешнего сервиса |
| US-101 | ВЫСОКИЙ | Чувствителен к безопасности, надёжность доставки email |
| US-102 | СРЕДНИЙ | Проблемы точности данных при больших наборах |
| US-104 | НИЗКИЙ | Простая фича, чётко определённый scope |
5. Вклад в Definition of Done:
- Все критерии приёмки проверены с проходящими тест-кейсами
- Негативное тестирование и граничные случаи выполнены для каждого story
- Нет открытых критических багов или багов высокой серьёзности
- Кросс-браузерное тестирование выполнено (US-101)
- Кросс-платформенное тестирование выполнено (US-103)
- Регрессионный набор проходит
- Тест-кейсы задокументированы и привязаны к stories
Антипаттерны Тестирования в Спринте
Знать, чего не делать, так же важно, как знать, что делать. Вот самые распространённые антипаттерны тестирования в спринте:
1. Мини-Водопад
Проблема: Вся разработка происходит в первой половине спринта, всё тестирование — во второй. Это создаёт узкое место в тестировании и гарантирует, что баги будут найдены поздно.
Решение: Разработчики и тестировщики работают параллельно. Тестируйте stories по мере их завершения, а не в конце.
2. Пропущенная Регрессия
Проблема: Команда пропускает регрессионное тестирование, потому что «мы изменили только одну вещь». Это одно изменение ломает три другие фичи.
Решение: Всегда запускайте регрессионные тесты, даже для малых изменений. Автоматизируйте регрессионные тесты, чтобы это было безболезненно.
3. Невидимый Тестировщик
Проблема: QA не участвует в Sprint Planning или Retrospective. Тестирование воспринимается как второстепенная задача.
Решение: QA должен посещать и активно участвовать во всех событиях Scrum. Если вас исключают, поднимите это как impediment.
4. «Готово», Которое Не Готово
Проблема: Stories помечаются как «готовые», когда код написан, пропуская тестирование. QA находит критические баги в якобы готовых stories в конце спринта.
Решение: Обеспечьте соблюдение Definition of Done. Story не готов, пока все критерии DoD, включая тестирование, не выполнены.
5. Спринт Багов
Проблема: Команда тратит целый спринт на исправление багов из предыдущего спринта вместо создания новой ценности.
Решение: Исправляйте баги по мере нахождения, в том же спринте. Включайте время на исправление багов в планирование ёмкости спринта.
Профессиональные Советы для QA в Scrum
Работайте в паре с разработчиками. Когда разработчик заканчивает фичу, сядьте вместе на 10 минут. Он демонстрирует, вы задаёте вопросы. Это выявляет очевидные проблемы до формального тестирования.
Автоматизируйте Definition of Done. Если ваш DoD требует прохождения unit-тестов и проверок покрытия кода, автоматизируйте эти проверки в CI-пайплайне. DoD должен быть проверяемым, а не декларативным.
Отслеживайте метрику «сбежавших дефектов». Считайте, сколько багов найдено в продакшене по сравнению со спринтом. Нисходящий тренд означает, что ваше тестирование в спринте улучшается.
Уточняйте stories до спринта. Участвуйте в сессиях refinement бэклога. Чем больше вы проясните требования до Sprint Planning, тем меньше сюрпризов во время тестирования.
Создайте чеклист тестирования для спринта. Создайте многоразовый чеклист для каждого спринта: тестовое окружение готово, тестовые данные подготовлены, регрессионный набор обновлён. Последовательность предотвращает упущения.