Agile и Scrum для QA-инженеров: что реально нужно знать

В Waterfall QA проверял готовую работу в конце многомесячного цикла. В Scrum QA входит в команду строящую продукт, и это меняет когда ты вовлекаешься и за что отвечаешь. Критерии приёмки написанные Product Owner становятся твоими тест-кейсами; на планировании спринта ты ловишь неясные требования до начала разработки; а «готово» означает что тесты проходят в CI, а не просто что код смёрджен.

Waterfall vs Agile: почему это важно

Waterfall строился строго поэтапно: сначала требования, потом дизайн, потом разработка, потом QA, потом релиз. Каждая фаза завершается до начала следующей. QA происходил в конце, после того как разработчики заканчивали работу.

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

Agile — ответ на это. Вместо одного большого релиза после месяцев работы, продукт строится и выпускается небольшими инкрементами, обычно двухнедельными циклами. QA входит в каждый цикл, а не стоит после него.

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

Фреймворк Scrum

Agile задаёт ценности и принципы, а Scrum предоставляет конкретный фреймворк который большинство команд использует для их реализации. Когда кто-то говорит «мы работаем в Agile», он почти всегда имеет в виду Scrum.

Роли

Product Owner (PO)

Владеет бэклогом продукта: приоритизированным списком всего что команда будет строить. PO решает что строится и в каком порядке, исходя из бизнес-ценности. Нетехническая роль, но требует понимания потребностей пользователей и умения объяснять их достаточно чётко чтобы разработчики могли реализовать.

Scrum Master

Обеспечивает процесс. Проводит церемонии, устраняет блокеры, защищает команду от внешних помех. Не менеджер, не раздаёт задачи. Скорее процессный коуч.

Команда разработки

Обычно 5–9 человек: разработчики, QA-инженеры, иногда UX. Кросс-функциональная: команда коллективно отвечает за поставку рабочего программного обеспечения.

В Scrum QA входит в команду разработки, а не стоит отдельно от неё. Ты не «отдел QA проверяющий работу разработчиков». Ты участник команды с конкретным набором навыков, вносящий вклад в общую цель.

Артефакты

Product Backlog

Полный список функций, багфиксов и технических работ которые команда может выполнить. PO владеет им и расставляет приоритеты. Элементы наверху — самые важные и детализированные. Элементы внизу — размытые. Они уточняются по мере продвижения наверх.

Sprint Backlog

Подмножество product backlog-а которое команда берёт на один спринт. Формируется во время Sprint Planning.

User Story

Стандартный формат для элементов бэклога:

Как [тип пользователя],
я хочу [какую-то цель],
чтобы [какая-то причина].

Пример:

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

User story описывает намерение, а не реализацию. Как это строить — решение команды.

Критерии приёмки

Конкретные условия которым история должна соответствовать чтобы считаться готовой. Пишет PO, проверяет QA.

Пример:

Given я нахожусь на странице элементов
When я выбираю "In Progress" из фильтра по статусу
Then отображаются только элементы со статусом "In Progress"
Then элементы с другими статусами не видны
Then выбор фильтра сохраняется при обновлении страницы

Это и есть твои тест-кейсы. Когда все критерии приёмки выполнены, история готова.

Definition of Done (DoD)

Командное соглашение о том что означает «готово». Обычно включает: код написан, код проверен, тесты написаны, тесты проходят, задеплоено на staging, документация обновлена.

Вклад QA в DoD обычно: автоматизированные тесты написаны и проходят в CI, ручное исследовательское тестирование завершено, нет открытых критических/высоких багов.

Цикл спринта

Спринт длится фиксированный период (обычно две недели), за который команда строит набор функций. Цикл повторяется.

Sprint Planning (начало спринта)

Команда выбирает элементы из product backlog для спринта. Элементы разбиваются на задачи, оцениваются и распределяются.

Роль QA в Sprint Planning

• Задавать уточняющие вопросы по критериям приёмки
• Выявлять тестовые сценарии которые PO не предусмотрел
• Отмечать элементы с недостаточной детализацией для тестирования (отправлять на доработку)
• Оценивать трудозатраты на тестирование. Если история требует 3 дня разработки, сколько займёт тестирование?

Daily Standup (каждый день, ~15 минут)

Три вопроса на каждого участника:

1. Что я делал вчера?

2. Что делаю сегодня?

3. Есть ли у меня блокеры?

Коротко, по существу, без решения проблем. Если что-то требует глубокого обсуждения, это происходит после standup с нужными людьми.

Типичные обновления QA на standup

«Вчера закончил тестирование функции фильтрации, нашёл один баг и залогировал. Сегодня тестирую форму в модальном окне. Блокеров нет.» Или: «Вчера был заблокирован потому что staging-окружение было недоступно. Сегодня оно поднялось, продолжаю тесты загрузки. Блокеров нет.»

Sprint Review (конец спринта)

Команда демонстрирует завершённую работу стейкхолдерам: PO, менеджерам, иногда клиентам. Показывается только работа соответствующая Definition of Done.

Роль QA в Sprint Review

Подтверждать что готово а что нет: частично готовое не считается. Иногда демонстрировать тестовые сценарии, а не только функции. Отмечать всё что завершено но имеет известные ограничения.

Sprint Retrospective (конец спринта)

Команда рефлексирует по процессу, а не по продукту. Что прошло хорошо? Что нет? Что меняем в следующем спринте?

Три категории: Keep (то что работает хорошо), Stop (то что не работает), Start (то что стоит попробовать).

Здесь QA часто поднимает процессные проблемы: тесты слишком долго работают в CI, разработчики ломают тестовое окружение без предупреждения, истории приходят в спринт без критериев приёмки.

Внутри спринта: между планированием и review

Типичный рабочий поток QA во время спринта:

Тестирование параллельно с разработкой, а не после: вот ключевое отличие от Waterfall.

Жизненный цикл бага в Scrum

Когда находишь баг:

1. Логируешь с чёткими шагами воспроизведения, ожидаемым и фактическим поведением, серьёзностью

2. Связываешь с историей в которой он найден

3. Обсуждаешь с разработчиком. Это баг или непонимание требований?

4. Расставляешь приоритет вместе с PO. Критические баги блокируют спринт; незначительные можно отправить в бэклог

Уровни серьёзности багов

• Critical: блокирует основную функциональность, потеря данных, проблема безопасности. Исправлять немедленно.
• High: основная функция сломана, обходного пути нет. Исправлять в этом спринте.
• Medium: функция частично сломана или есть обходной путь. Исправлять в следующем спринте.
• Low: косметическая проблема, незначительное неудобство. Идёт в бэклог.

Ключевые термины которые услышишь в Scrum-команде

| Термин | Значение |

|--------|---------|

| Backlog refinement | Регулярная встреча для просмотра и детализации предстоящих элементов бэклога |

| Velocity | Сколько стори-поинтов команда выполняет за спринт в среднем |

| Story points | Относительная мера усилий (не часы). 1, 2, 3, 5, 8, 13. |

| Epic | Крупная функция разбитая на несколько историй |

| Spike | Ограниченная по времени исследовательская задача (исследование, proof of concept) |

| Technical debt | Работа отложенная ради скорости, которую в итоге всё равно нужно сделать |

| Blocker | Что-то мешающее прогрессу, требует немедленного внимания |

| WIP limit | Максимальное количество задач одновременно в работе (предотвращает переключение контекста) |

Kanban: когда встретишь его вместо Scrum

Некоторые команды используют Kanban вместо Scrum. Разница: нет спринтов. Работа течёт непрерывно. Доска с колонками (To Do, In Progress, Testing, Done) отслеживает состояние.

Роль QA в Kanban: берёшь истории из «In Progress» когда разработчики отмечают их как готовые, перемещаешь в «Testing», и в «Done» когда они проходят. Никаких церемоний, никаких фиксированных циклов. Больше подходит для поддержки и багфиксов, чем для разработки функций.

Что реально спрашивают на собеседованиях

«Расскажи о своём Agile-опыте»

Говори о каких церемониях участвовал, какова была твоя роль в каждой, и приведи конкретный пример. «Я работал в команде с двухнедельными спринтами. Участвовал в daily standups, тестировал истории по мере их выхода из разработки, участвовал в ретроспективах. В одном спринте поднял проблему что истории приходят без критериев приёмки, и мы ввели шаг refinement который это исправил.»

«Как справляешься с тестированием в коротком спринте?»

«Начинаю писать тест-кейсы во время Sprint Planning, до начала разработки. Так когда история помечается как готовая для тестирования, я не начинаю с нуля. Также тестирую истории по отдельности по мере их завершения, а не пакетом в конце.»

«В чём разница между багом и недостающим требованием?»

«Баг: поведение которое расходится с задокументированными критериями приёмки. Недостающее требование: поведение не покрытое никакими критериями приёмки. Приложение работает как указано, но спецификация была неполной. Недостающие требования возвращаются к PO, баги отправляются к разработчику.»