Вы уже знаете, что Scrum — это гибкий подход к разработке, при котором команда работает небольшими итерациями, называемыми спринтами. Мы разобрали основные роли, встречи и процессы, которые помогают команде двигаться вперёд. Теперь давайте углубимся в то, как именно тестировщик становится не просто наблюдателем, а полноценным участником этой системы.
Многие новички думают, что тестировщик начинает работать только тогда, когда разработчик «закончил» задачу. Это устаревшее представление. В современной Scrum-команде всё иначе: тестирование в спринте — это не финальный этап, а процесс, встроенный в каждый день.
Вовлечение тестировщика: с чего всё начинается
Ключевое понятие — вовлечение тестировщика. Это означает, что вы участвуете в работе команды с самого начала, а не ждёте готового продукта.
Ещё до старта спринта проходят встречи по уточнению требований — refinement. Именно здесь тестировщик уже вносит вклад:
- Читает User Story (мы подробно разберём их позже),
- Задаёт вопросы аналитику и разработчику,
- Проверяет, достаточно ли деталей для тестирования.
💡 Совет: Если в описании задачи не сказано, что делать при пустом поле или неверном формате даты — это ваш сигнал к действию. Спросите об этом на refinement. Это и есть вовлечение.
Такой подход называется shift-left testing — смещение проверки влево по циклу разработки. Чем раньше вы зададите вопрос, тем меньше багов появится позже.
Как тестировщик участвует в ключевых встречах
Каждая встреча в Scrum — это возможность для тестировщика повлиять на качество. Давайте разберём, как именно.
Планирование спринта (Sprint Planning)
Здесь команда решает, какие задачи войдут в спринт.
Ваша роль:
- Оценить, сколько времени займёт тестирование.
- Указать, если для проверки нужны внешние данные, тестовые аккаунты или доступ к API.
- Спросить о критериях принятия — что значит «задача готова»?
Пример диалога:
Разработчик: «Сделаем форму регистрации».
Тестировщик: «А какие поля обязательные? Нужно ли проверять уникальность email? Будет ли капча?»
Эти вопросы помогают избежать недопонимания.
Ежедневные стендапы (Daily Standup)
Короткая встреча, где каждый говорит:
- Что сделал вчера,
- Что планирует сегодня,
- Есть ли препятствия.
Ваш вклад:
- Сообщайте, какие задачи вы тестируете.
- Если не можете проверить функцию из-за бага — скажите об этом.
- Если нашли критический дефект — команда может пересмотреть приоритеты.
Пример:
«Вчера проверял форму входа. Нашёл баг: при вводе кириллицы в логин приложение падает. Создал баг-репорт в Jira. Сегодня жду исправления, чтобы проверить».
Это помогает команде видеть риски в реальном времени.
Демонстрация (Sprint Review)
Команда показывает заказчику, что было сделано.
Ваша роль:
- Продемонстрировать протестированный функционал.
- Показать найденные, но неисправленные баги.
- Получить обратную связь от заказчика.
Ретроспектива (Sprint Retrospective)
Обсуждение: что прошло хорошо, что можно улучшить.
Вы можете предложить:
- Добавить больше времени на тестирование,
- Улучшить чек-листы,
- Внедрить автоматические проверки для рутинных задач.
Тестирование в спринте: как это выглядит на практике
Давайте посмотрим на типичный день тестировщика в Scrum-спринте:
| Время | Действие |
|---|---|
| 10:00 | Участие в дейли-стенде: отчитываюсь о прогрессе |
| 10:30 | Проверяю исправление бага из вчерашнего репорта |
| 11:00 | Начинаю тестирование новой задачи: регистрация через соцсети |
| 12:00 | Нахожу ошибку: после входа через Google не подтягивается email |
| 12:15 | Создаю баг-репорт в Jira с шагами воспроизведения |
| 14:00 | Участвую в refinement: обсуждаем новую форму оплаты |
| 15:00 | Обновляю чек-лист для тестирования форм |
Обратите внимание: вы не просто выполняете тесты. Вы влияете на процесс, помогаете команде принимать решения и предотвращаете проблемы.
Интеграция QA в команду: не просто роль, а культура
Интеграция QA в команду — это когда качество становится общей ответственностью.
- Разработчик пишет код с учётом тестирования,
- Аналитик учитывает сценарии проверки,
- Продукт-овнер включает проверку тестировщиком в Definition of Done (DoD).
DoD — это список условий, которые должны быть выполнены, чтобы задача считалась завершённой. Например:
- Код прошёл ревью,
- Написаны тесты,
- Проверено на разных устройствах,
- Подтверждено тестировщиком.
🔄 Важно: Если тестировщик не проверил — задача не завершена. Это ваша сила в команде.
Почему это важно для вашей карьеры
Компании ищут не просто «охотников за багами», а активных участников процесса.
- В резюме вы можете написать: «Участвовал в refinement, влиял на требования, снижал количество багов на 30% за счёт раннего вовлечения».
- На собеседовании — рассказать, как вы предложили улучшить DoD или помогли избежать ошибки на этапе планирования.
Такой опыт выделяет вас среди других кандидатов.
Что дальше?
Вы теперь понимаете, где и как тестировщик участвует в Scrum. Но чтобы быть эффективным, важно уметь правильно говорить в команде:
- Как вежливо указать на ошибку,
- Как сформулировать проблему, чтобы вас услышали,
- Как избежать конфликтов при обсуждении багов.
Мы подробно разберём это в следующей теме — Эффективная коммуникация в IT-команде. Это ваш следующий шаг к тому, чтобы стать не просто тестировщиком, а ценным членом команды.