1. Планирование спринта (Sprint Planning)

Спринт начинается с Sprint Planning — встречи, на которой команда определяет задачи и цели на спринт.

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

Что происходит:

• Формулируются цели спринта. На Sprint Planning команда вместе с владельцем продукта (Product Owner) решает, что нужно достичь в течение спринта. Это помогает всем участникам сосредоточиться на единой цели и двигаться в одном направлении.
• Команда выбирает задачи из общего бэклога продукта, которые будут выполняться. Эти задачи детализируются и оцениваются, чтобы команда могла реалистично распределить свои усилия. Не все задачи из бэклога одинаково важны. На планировании расставляются приоритеты, чтобы сначала выполнять те задачи, которые принесут максимальную ценность.
• Обсуждаются критерии приемки (Definition of Done) и оценивается объем работы.

Что важно на этом этапе для тестировщиков:

• Sprint Planning дает возможность всей команде задать вопросы по задачам, чтобы исключить недопонимание. Для тестировщика это шанс уточнить:

1) Какие сценарии должны быть покрыты тестами.
2) Какие требования могут влиять на качество продукта.

• Понять, что нужно протестировать.
• Заранее подготовить тестовые сценарии для задач, запланированных на спринт.
• Убедиться, что тестирование учтено в оценке задач.

2. Груминг бэклога (Backlog Grooming или Refinement)

Груминг (Grooming) — это регулярная встреча, которая помогает поддерживать бэклог в актуальном состоянии. Обычно она проводится до планирования спринта.

Задачи груминга:

• Описать задачи более конкретно.
• Эпики разбиваются на меньшие задачи.
• Задачи сортируются по важности.
• Команда определяет примерный объем работы.

Что важно на этом этапе для тестировщиков:

• Обсудить тестовые требования.
• Предложить уточнения к пользовательским историям.
• Выявить риски тестирования заранее.

Груминг (Backlog Grooming) и Планирование спринта (Sprint Planning) — это два ключевых этапа работы в Agile, которые часто путают, особенно новички. Хотя оба процесса связаны с задачами бэклога, они преследуют разные цели и проводятся на разных этапах. Вот в чем основные отличия:

Цель встречи:

• Цель груминга — подготовить бэклог продукта к будущим спринтам. Это включает в себя уточнение требований, оценку задач и расстановку приоритетов. Груминг помогает держать бэклог в актуальном состоянии, чтобы команда всегда имела четкое представление о предстоящих задачах.
• Цель планирования — сформировать бэклог спринта, то есть выбрать конкретные задачи из бэклога продукта, которые команда возьмет в работу в предстоящем спринте. Это более конкретный и целенаправленный процесс, где определяется объем работы, согласуются задачи и формируется цель спринта.

Когда проводится:

• Груминг проводится регулярно (например, раз в неделю или раз в две недели) для поддержания порядка в бэклоге. Он не привязан к началу спринта и может проводиться в любой момент.
• Планирование всегда проводится в начале каждого спринта и знаменует его старт.

Основное содержание

• Груминг: Уточнение описаний задач и критериев приемки (Definition of Ready), Уточнение и корректировка приоритетов задач, Разделение крупных задач (эпиков) на более мелкие, Первичная оценка задач (например, в Story Points).
• Planning: Выбор задач для спринта из подготовленного бэклога, Определение цели спринта (Sprint Goal), Оценка задач в деталях, если она не была выполнена на груминге, Распределение задач между участниками команды.

3. Ежедневные встречи (Daily Stand-ups)

Daily Stand-ups — это короткие ежедневные встречи, которые помогают команде синхронизировать работу и выявлять проблемы на ранних стадиях. Для тестировщиков это отличная возможность оставаться на одной волне с коллегами и активно участвовать в решении задач.

На встрече обсуждают:

• Что каждый сделал вчера?
• Что планирует сделать сегодня?
• Какие есть препятствия?

Для тестировщика важно:

• Сообщить о статусе тестирования задач.
• Указать на проблемы, например, блокирующие баги.
• Попросить помощь команды для устранения технических или процессных препятствий.

Как использовать Daily для устранения блокеров и улучшения взаимодействия:

• Сфокусируйтесь на трех ключевых вопросах:

1) Что я сделал вчера?
2) Что я планирую сделать сегодня?
3) Есть ли что-то, что мешает мне двигаться дальше?

• Если вы столкнулись с проблемой, это ваш шанс сообщить команде. Типичные блокеры для тестировщика:

1) Окружение для тестирования не настроено.
2) Функционал не готов или баги мешают начать тестирование.
3) Требуются уточнения по задаче от Product Owner или разработчика.
Важно не просто описывать проблему, но и предлагать решения или просить конкретной помощи.

• Используйте Daily для обсуждения, когда будут готовы задачи для тестирования. Например:

1) Уточните статус задач, которые вы ждете от разработки.
2) Согласуйте, когда можно начинать тестирование промежуточных версий.
3) Убедитесь, что исправленные баги переносятся обратно в тестирование.

• Расскажите, какие задачи вы протестировали и какие тесты еще планируете выполнить. Это помогает команде видеть ваш вклад и вовремя реагировать, если что-то идет не так.

Еще до того, как работать из дома стало модно, на одном из проектов у нас была особая традиция: каждый день мы всей командой собирались в офисе на daily. Эти встречи мы называли просто — stand-up’ами.
Каждое утро, буквально за 10-15 минут, мы обсуждали, что было сделано вчера, какие планы на сегодня и есть ли у кого-то блокеры. Формат был максимально простой: все стояли в кругу (да, именно стояли — так обсуждения шли быстрее и продуктивнее).

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

Иногда я вспоминаю те stand-up’ы с особой теплотой. Это были не просто митинги, а возможность увидеть всех коллег, обменяться идеями и зарядиться командным настроением на весь день.

4. Планирование программного инкремента (PI Planning)

PI Planning — это масштабное мероприятие, проводимое в рамках SAFe (Scaled Agile Framework), если команда работает в больших организациях. Оно охватывает планирование на несколько спринтов вперед.

Основные цели PI Planning:

• Установить общие цели для всех команд.
• Определить зависимости между командами.
• Сформировать план на 5–10 недель.

Роль тестировщика:

• Участвовать в обсуждении планов.
• Понять, какие модули или функции системы будут тестироваться.
• Заранее оценить объем тестирования и возможные зависимости.

На одном из проектов я работала в компании, где PI Planning был настоящим событием, которое мы ждали каждые три месяца. Этот процесс не только помогал синхронизировать работу, но и превращался в уникальный опыт, объединяющий команды.

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

Первый день начинался с теплого приема: нас встречали горячий кофе и свежие круассаны — идеальный способ зарядиться энергией перед интенсивным днем.

Далее следовали 6–7 часов оживленных бесед и брейнштормов. Мы встречались с другими командами, обсуждали общие цели, согласовывали задачи на следующий квартал, разбирали зависимости и выявляли риски.
После насыщенного рабочего дня нас ждал неформальный вечер. Вечеринки, совместные ужины или просто непринужденное общение — это был важный элемент, который укреплял связи между командами.

На следующий день мы снова возвращались к планированию, подводили итоги, уточняли детали и доводили до идеала наши Program Backlogs. К концу второго дня у нас был четкий план на следующие три месяца, и мы возвращались домой вдохновленными и готовыми к новым вызовам.

5. Демонстрация результатов (Sprint Review)

Sprint Review (Demo) это важный этап Agile-процесса, который часто воспринимается исключительно как демонстрация проделанной работы. Однако, на самом деле, Review играет гораздо более значимую роль, включая проверку качества результата. Вот почему Review — это больше, чем просто показ функций.

Цель:

• Показать результат работы заинтересованным сторонам.
• Получить обратную связь.
• Оценить, достигнуты ли цели спринта.

Тестировщику важно:

• Убедиться, что все демонстрируемые задачи протестированы.
• Быть готовым ответить на вопросы по качеству работы или выявленным ограничениям.
• При необходимости можно подготовить краткое резюме результатов тестирования. Например, статус всех задач, количество найденных и исправленных багов.

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

• Убедиться, что задачи соответствуют критериям приемки (Definition of Done). Это означает, что функционал:
• Полностью протестирован.
• Не имеет критических дефектов.
• Документирован и готов к использованию.
• Проверить, насколько реализация отвечает ожиданиям заказчиков и конечных пользователей.

Качество — это не только отсутствие багов, но и соответствие бизнес-требованиям. На Review участники обсуждают:

• Достижение целей спринта.
• Насколько выполненные функции решают задачи пользователя.
• Возможные улучшения и корректировки, чтобы повысить ценность продукта.

Если задача сделана «технически правильно», но не решает проблемы пользователя, ее качество оказывается под вопросом.

Во время Review присутствуют не только члены команды, но и Product Owner, а иногда и конечные пользователи или другие стейкхолдеры. Они:

• Проверяют, соответствует ли функционал ожиданиям.
• Даю обратную связь по качеству реализации, включая UX/UI.
• Выявляют, что можно улучшить до релиза.

Для тестировщика это возможность узнать о потенциальных улучшениях или новых сценариях, которые стоит протестировать в будущем.


Review позволяет всей команде убедиться, что все части продукта работают как единое целое. Это важный этап для:

• Проверки интеграции выполненных задач.
• Анализа, не нарушила ли новая функциональность другие части продукта.

6. Ретроспектива (Sprint Retrospective)

Sprint Retrospective - это важная часть Agile-процесса, которая позволяет команде анализировать прошедший спринт и находить способы улучшения. Для тестировщиков это особенно полезно, так как помогает не только решать текущие проблемы, но и развивать процессы тестирования в целом.

Основные вопросы:

• Что работало хорошо?
• Что можно улучшить?
• Какие действия предпринять для улучшения?

Для тестировщика ретро — это отличная возможность:

• Указать на проблемы, влияющие на тестирование (например, нехватка времени, сложности с окружением).
• Предложить улучшения, такие как внедрение автоматизации или корректировка процесса тестирования.

Ретроспектива предоставляет безопасное пространство, где можно открыто обсудить, что пошло не так. Для тестировщиков это возможность поднять такие проблемы, как:

• Недостаток времени на тестирование.
• Проблемы с тестовым окружением (например, нестабильность).
• Недостаточная четкость требований, что затрудняло тестирование.
• Задержки в исправлении багов, которые блокировали тесты.

Если в ходе спринта выявлены критические баги, ретроспектива позволяет проанализировать причины их появления:

• Были ли тестовые сценарии недостаточно детализированы?
• Пропустило ли тестирование определенные сценарии?
• Возникли ли проблемы из-за недостаточной автоматизации?

Команда может выработать меры, чтобы предотвратить повторение таких ошибок.

Retro помогает находить узкие места в тестировании и предлагать улучшения. Примеры:

• Внедрение новых инструментов или методов тестирования (например, автоматизация регрессионных тестов).
• Улучшение процесса создания тест-кейсов.
• Уточнение критериев приемки задач (Definition of Done).

Ретроспектива — это площадка для обмена опытом. Тестировщики могут:

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

Ретроспектива заканчивается созданием конкретного плана улучшений. Для тестировщиков это может быть:

• Подготовка чек-листа для типичных тестов.
• Создание новых автотестов.
• Введение регулярного груминга требований, чтобы заранее выявлять риски для тестирования.

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

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

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

На ретроспективе я решила поднять этот вопрос. Сначала я описала ситуацию:

• Как поздняя передача задач влияет на тестирование.
• Почему работа в таких условиях снижает общее качество продукта.

После обсуждения я предложила ввести минимальный Definition of Ready (DoR) для задач перед началом разработки.

Что это значило для нас?

1. Задачи не начинали разрабатывать, пока они не соответствовали критериям DoR.
2. Я предложила такие критерии для DoR:

• Четко сформулированные требования (не только описание, но и примеры).
• Определенные критерии приемки.
• Наличие тестового окружения, если это необходимо.

Мы договорились, что перед началом разработки Product Owner будет проверять задачи на соответствие этим критериям, а команда, включая меня, могла вносить свои замечания на этапе груминга.

После внедрения DoR ситуация улучшилась. Теперь к моменту начала разработки задачи уже имели ясное описание и согласованные критерии приемки. Это сократило вопросы и доработки в процессе. Я могла подключаться к задачам еще на этапе разработки, тестируя их поэтапно и предотвращая накопление дефектов. Задачи попадали на тестирование раньше, что давало больше времени для полноценной проверки.

На следующей ретроспективе я заметила, что команда тоже оценила изменения. Разработчики реже сталкивались с доработками из-за недостаточных требований, а качество продукта заметно выросло.

7. Планирование релиза (Release Planning)

Release Planning используется для согласования крупных поставок продукта. Это может быть отдельный митинг или часть PI Planning.

Что обсуждается:

• Какие функции будут включены в релиз?
• Сроки поставки.
• Потенциальные риски.

Для тестировщика важно:

• Заранее запланировать регрессионное тестирование.
• Оценить объем работы на этапе стабилизации продукта.
• Подготовить тестовые планы для релиза.

8. Митинги синхронизации (Scrum of Scrums)

Когда несколько команд работают над одним проектом, используются встречи Scrum of Scrums, чтобы синхронизировать их работу.

Цель:

• Обсудить прогресс работы каждой команды.
• Выявить межкомандные зависимости и блокеры.

Для тестировщика:

• Участвовать в обсуждении интеграционного тестирования.
• Сообщать о багах, влияющих на несколько команд.

PI Planning и Scrum of Scrums дают всем участникам проекта ясное понимание общей картины, что позволяет командам работать в едином ритме. Эти мероприятия помогают заранее выявлять зависимости, проблемы и риски, что минимизирует задержки и ошибки. Согласованные цели и синхронизация работы уменьшают дублирование усилий и улучшают распределение ресурсов.

Немаловажная идея PI Planning и Scrum of Scrums - обсуждение целей и задач на межкомандных уровнях формирует чувство сопричастности к успеху проекта у всех участников. PI Planning и Scrum of Scrums устраняют барьеры в общении между командами, что особенно важно в удаленных или распределенных коллективах.