Agile и Scrum для тестировщика: что это значит на практике

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

Что такое Agile простыми словами

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

Scrum и Kanban — конкретные способы это организовать. Scrum работает отрезками фиксированной длины (спринтами), Kanban — непрерывным потоком без отрезков.

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

Спринт глазами тестировщика

Событие	Что происходит	Ваша роль
Планирование	Команда набирает задачи на спринт	Задать вопросы по требованиям, оценить тестирование
Ежедневная встреча	Короткий обмен статусом	Сказать, что проверено и что блокирует
Работа в спринте	Разработка и проверка идут параллельно	Готовить чек-листы заранее, проверять по мере готовности
Демонстрация	Показ результата заказчику	Убедиться, что показывают то, что работает
Ретроспектива	Что улучшить в процессе	Поднять проблемы: поздние сборки, размытые требования

Главная проблема и как с ней жить

Классическая беда Scrum-команд: разработка занимает весь спринт, а тестирование остаётся на последние два дня. В итоге проверять некогда, дефекты чинить некогда, и часть задач переезжает.

Полностью это не лечится, но смягчается несколькими вещами.

1. Готовьте проверки заранее. Чек-лист пишется по требованиям, а не по готовой функции. К моменту сборки у вас уже всё готово.
2. Проверяйте по частям. Не ждите, пока задача будет готова целиком: часто можно проверить API раньше, чем появится интерфейс.
3. Говорите о рисках заранее. На третий день спринта, а не на последний: «если сборка придёт в четверг, я успею только основной сценарий».
4. Поднимайте на ретроспективе. Это системная проблема команды, а не ваша личная скорость.

Definition of Done — ваш главный союзник

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

Разумный DoD включает: код написан и прошёл ревью, модульные тесты есть и зелёные, функция проверена тестировщиком, дефекты критичного уровня исправлены, документация обновлена.

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

Оценка задач тестирования

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

Рабочий ориентир: время на прохождение сценариев умножьте на два. Вторая половина уйдёт на разбор находок, оформление, перепроверку исправлений и переключения между задачами. Это не запас «на всякий случай» — это реальная структура работы.

И отдельно закладывайте время на регресс, если он в этом спринте. Подробнее про его объём — в статье про регрессионное тестирование.

Kanban: чем отличается для тестировщика

Если в команде Kanban, а не Scrum, меняется ритм. Нет спринтов и общей даты — задачи текут по доске непрерывно, и проверка начинается сразу, как задача доехала до вашей колонки.

Что становится важнее:

• Ограничение незавершённой работы. Если в колонке «Testing» висит восемь задач, поток встал — и это видно всем, а не только вам.
• Скорость реакции. Задачу берут в проверку сразу, а не копят до конца недели: иначе доска превращается в свалку.
• Регресс по расписанию. Без спринтов нет естественной точки для полного прогона, его планируют отдельно.

Плюс для тестировщика: нет аврала в последние два дня. Минус: труднее выделить время на большие задачи вроде обновления документации — их приходится защищать отдельно.

Чего в Agile не отменяли

Распространённое заблуждение: раз Agile ценит работающий продукт выше документации, значит документация не нужна. В манифесте написано «выше», а не «вместо».

• Чек-листы нужны. Просто они короче и живут в задаче, а не в отдельном документе на тридцать страниц.
• Требования нужны. Пусть в виде пользовательской истории с критериями приёмки, но они должны быть проверяемыми.
• Тест-план нужен. В облегчённом виде: что в объёме спринта, на чём проверяем, когда считаем готовым.

Как это оформлять компактно — в разборе тест-плана и отчёта.