Большинство современных команд работают по Agile — гибкому подходу, где продукт делают маленькими кусочками, короткими циклами, а не одним огромным рывком. Самая распространённая его разновидность — Scrum. Для тестировщика это значит одно: вы не ждёте готовый продукт в конце, а работаете вместе с разработкой, с первого дня цикла.

Разберём, как устроен Scrum и где в нём ваше место, чтобы на реальной работе вы понимали, что происходит вокруг и что от вас ждут на каждой встрече.

Спринт и бэклог

Работа в Scrum разбита на спринты — короткие отрезки, обычно одна-две недели. За спринт команда берёт небольшой набор задач и доводит их до готовности.

Откуда берутся задачи: есть бэклог — общий список всего, что нужно сделать в продукте, отсортированный по важности. На спринт из верхушки бэклога выбирают то, что успеют. Задачи часто описывают как пользовательские истории (user story) — коротко, от лица пользователя: «Как покупатель, я хочу оплатить заказ картой, чтобы не платить наличными».

Ключевая идея для тестировщика: за один спринт задача проходит весь путь — от обсуждения до готовности, включая тестирование. Не «в этом спринте пишем, в следующем тестируем», а всё сразу.

Церемонии Scrum и ваша роль в них

В Scrum есть несколько регулярных встреч («церемоний»). На каждой у тестировщика своя роль:

  • Планирование (planning). В начале спринта команда решает, что берёт в работу. Ваша задача — оценить, что и как будете тестировать, задать вопросы по задачам, прикинуть, что успеете. Часто именно здесь вы вскрываете неясности в требованиях.
  • Дейли (daily, летучка). Короткая ежедневная встреча «что делал, что буду, что мешает». Вы говорите, что тестируете, где ждёте починок, что вас блокирует.
  • Обзор (review, демо). В конце спринта показывают, что сделали. Вы уже проверили это к моменту показа — на демо не должно всплывать сюрпризов.
  • Ретроспектива (retro). Команда обсуждает, что в процессе шло хорошо, а что улучшить. Тестировщик поднимает проблемы качества: например, «задачи приходят на тест в последний день, не успеваем».

Почему тестирование идёт вместе с разработкой

В старом подходе (waterfall) тестирование стояло в конце, отдельным этапом. В Agile так нельзя — цикл слишком короткий. Поэтому тестирование «размазано» по всему спринту:

  • В начале вы разбираете задачи и задаёте вопросы (баги в требованиях ловятся тут).
  • Пока разработчик пишет код, вы готовите тест-кейсы и данные.
  • Как только функция готова — сразу проверяете, не дожидаясь конца спринта.
  • Ближе к концу — регресс: не сломало ли новое старое.

Отсюда важное следствие: тестировщик и разработчик — партнёры, работающие бок о бок, а не «конвейер», где один сдал, другой принял.

Definition of Done — когда задача готова

Полезное понятие — Definition of Done (DoD), «определение готовности». Это общий для команды чек-лист, при каком условии задачу можно считать завершённой. Обычно туда входит и «протестировано»: например, «код написан, ревью пройдено, тесты пройдены, багов с высоким приоритетом нет».

Для тестировщика DoD — это защита: задача не «готова», пока не проверена. Это не даёт выпускать непроверенное под давлением сроков.

Где это применяется

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

Где спотыкаются начинающие:

  • Ждут, пока «всё сделают», и получают всю работу в последний день спринта. В Agile нужно включаться сразу и тестировать по мере готовности.
  • Молчат на встречах. Планирование и дейли — ваш шанс задать вопросы и сказать о блокерах. Молчание = проблемы всплывут поздно.
  • Считают разработчика противником. Вы делаете общее дело; баг — это не обвинение, а совместная находка.

Что учить дальше. Многое в спринте начинается с задачи и требований к ней. Как проверять именно то, что описано, и как работать с теми, кто пишет требования, — статья тестирование по требованиям.