Проведение тестирования в Agile/Scrum
Проведение тестирования в Agile/Scrum
Scrum-церемонии и участие QA
В Scrum есть несколько регулярных встреч — церемоний. Тестировщик участвует во всех из них.
Sprint Planning (Планирование спринта)
Команда договаривается, какие задачи войдут в следующий спринт.
Твоя роль:
- Оценить трудозатраты на тестирование — разработка займёт 3 дня, но и тестирование нужно закладывать
- Задавать вопросы по требованиям — если что-то неясно, лучше выяснить сейчас, а не в конце спринта
- Отмечать риски — «Эта задача затрагивает платёжный флоу, нужно регрессионное тестирование»
- Добавить задачи на тест-кейсы — написание тест-кейсов — это отдельная работа, её нужно оценивать
Daily Standup (Ежедневный стендап)
Короткая встреча (15 минут) для синхронизации команды.
Что говоришь ты:
- Что сделал вчера: «Протестировал задачу SHOP-142, нашёл 2 бага»
- Что делаешь сегодня: «Буду тестировать SHOP-145, напишу тест-кейсы для оплаты»
- Есть ли блокер: «Жду деплой на staging — разработчик обещал к 10:00»
Ошибка — говорить расплывчато: «Тестирую, всё нормально». Конкретность помогает команде.
Sprint Review (Обзор спринта / демо)
Команда демонстрирует заинтересованным сторонам (стейкхолдерам) то, что было выполнено за спринт.
Твоя роль:
- Участвуешь в демо, иногда сам показываешь протестированный функционал
- Подтверждаешь, что задача прошла тестирование
- Фиксируешь обратную связь для Backlog
Retrospective (Ретроспектива)
Команда анализирует прошедший спринт: что прошло хорошо, что можно улучшить.
Твоя роль:
- Предлагать улучшения процесса тестирования
- Поднимать проблемы: «Тестирование всегда скапливается в последние два дня спринта — нужно начинать раньше»
- Отмечать успехи команды — это тоже важно
Definition of Done (DoD)
DoD — это договорённость команды о том, когда задача считается по-настоящему завершённой.
Пример хорошего DoD:
Задача считается "Done", когда:
[ ] Разработка завершена, код прошёл ревью
[ ] Задача прошла тестирование QA
[ ] Критических багов нет (minor — допустимо по договорённости)
[ ] Документация обновлена (если применимо)
[ ] Задача задеплоена на staging
Если DoD в команде нет — предложи его создать. Это одно из самых ценных улучшений, которые ты можешь внести.
Тестирование внутри спринта
Антипаттерн: ждать конца спринта, чтобы начать тестировать. К этому моменту все задачи накапливаются, времени мало — качество страдает.
Правильно: тестировать каждую задачу по мере её готовности.
Неделя 1, день 3: разработчик завершил SHOP-141 → ты тестируешь
Неделя 1, день 4: разработчик завершил SHOP-143 → ты тестируешь
Неделя 2, день 2: разработчик завершил SHOP-145 → ты тестируешь
Это называют «непрерывным тестированием» внутри спринта.
Триаж багов
Не каждый найденный баг нужно исправлять немедленно. Триаж — это совместное решение команды о приоритете и судьбе бага.
| Вопрос | Варианты ответа |
|---|---|
| Критичность | Blocker / Critical / Major / Minor |
| Влияние | Блокирует пользователя / обходной путь есть |
| Что делать | Fix now / Fix in next sprint / Backlog / Won't fix |
Ты участвуешь в триаже и аргументируешь свою позицию на основе влияния на пользователя.
Что мы запомним
- Scrum-церемонии: Planning, Daily Standup, Sprint Review, Retrospective — ты участвуешь в каждой
- Definition of Done — командная договорённость о критериях «завершённости»; если DoD нет — предложи его создать
- Тестируй задачи по мере готовности, не копи всё на конец спринта
- На Standup говори конкретно: что сделал, что делаешь, что блокирует
- Триаж багов — совместное решение о приоритете; аргумент — влияние на пользователя