Вы уже умеете находить ошибки в интерфейсах, работать с эмуляторами и писать чёткие баг-репорты. Теперь важно понять, в какой среде вы будете это делать. Большинство IT-компаний в России уже давно перешли от старых, жёстких методов разработки к гибким подходам. И один из самых популярных — это Scrum.
Представьте: раньше программу делали год, а потом только запускали. Если пользователи сказали: «Нам это не нужно», — всё время и деньги были потрачены впустую. Именно так работал водопадный подход — линейный, без обратной связи.
Сегодня компании выпускают продукт по частям, каждые 2–4 недели. Получают обратную связь, корректируют курс. Это и есть Agile — не конкретный процесс, а подход, основанный на гибкости, итерациях и постоянном улучшении.
Agile (гибкая методология) — это не набор правил, а набор ценностей. Главное: работающий продукт важнее документации, сотрудничество важнее контрактов, адаптация к изменениям важнее следования плану.
Scrum — это одна из реализаций Agile. Самая распространённая. Именно в ней работают команды в Сбере, Тинькофф, Яндексе и многих других российских IT-компаниях.
Основные роли в Scrum
В Scrum нет начальников в привычном понимании. Есть три ключевые роли, каждая со своей ответственностью.
Продукт-овнер (Product Owner)
Это человек, который отвечает за ценность продукта. Он знает, что нужно делать и зачем.
- Собирает требования от бизнеса и пользователей
- Формирует и ведёт бэклог продукта — список задач, которые нужно реализовать
- Определяет приоритеты: что делать в этом спринте, а что — позже
Пример: в приложении банка нужно сначала сделать переводы, а не смену аватарки. Продукт-овнер принимает это решение.
Скрам-мастер (Scrum Master)
Это фасилитатор команды, а не руководитель. Его цель — помогать команде работать эффективно, а не контролировать.
- Следит, чтобы процессы Scrum соблюдались
- Убирает препятствия: если команда не может работать — он решает проблему
- Проводит встречи и следит за их продуктивностью
Важно: скрам-мастер не управляет разработчиками. Он как тренер команды — помогает им быть сильнее, а не указывает, как бежать.
Команда разработки
Это все, кто создаёт продукт: разработчики, тестировщики, аналитики, дизайнеры.
- Работает самоорганизованно — сама решает, как выполнить задачу
- Планирует свою работу на спринт
- Отвечает за результат вместе, а не по отдельности
Да, вы — часть команды. Ваш вклад в поиск багов и проверку функций так же важен, как и код разработчика.
Спринт: как работает цикл разработки
Центр Scrum — это спринт. Это фиксированный отрезок времени, обычно 2 недели, в течение которого команда создаёт рабочую версию продукта.
- Спринт начинается с планирования
- В середине — ежедневные короткие встречи
- В конце — демонстрация результата и анализ
За спринт команда должна выпустить минимально жизнеспособную часть функционала, которую можно показать и протестировать. Например, форму входа в приложение.
Представьте, что вы тестируете новую форму входа. Вместо того чтобы ждать месяц, пока всё будет готово, вы получаете её уже через 2 недели. Проверяете, находите баги, даёте обратную связь — и уже на следующем спринте всё исправлено.
Ключевые события в спринте
Планирование спринта
Команда собирается и решает: что мы будем делать в этом спринте и как мы это реализуем.
- Продукт-овнер предлагает задачи из бэклога
- Команда оценивает сложность и берёт столько, сколько реально успеет сделать
- Формируется бэклог спринта — список задач на 2 недели
На этом этапе уже важно ваше мнение как тестировщика: сколько времени займёт проверка функции? Есть ли риски?
Дейли-стенд (Daily Stand-up)
Каждый день, не дольше 15 минут, команда встаёт (или входит в звонок) и отвечает на три вопроса:
- Что я сделал вчера?
- Что я планирую сделать сегодня?
- Есть ли у меня препятствия?
Это не отчёт перед руководством, а синхронизация команды.
В 2025 году в российских компаниях всё чаще используют асинхронные дейли-стенды: обновления в Telegram или Slack утром.
Ревью спринта
В конце спринта команда показывает результат продукт-овнеру и заинтересованным лицам.
- Демонстрируется, что было сделано
- Собирается обратная связь
- Принимается решение: что дорабатывать, а что — переносить в следующий спринт
Вы как тестировщик уже подготовили баг-репорты и чек-листы — теперь вы показываете, где есть проблемы.
Ретроспектива
Команда анализирует: как прошёл спринт, что получилось, а что — нет.
- Обсуждают процессы, а не людей
- Ищут способы стать эффективнее
- Формулируют одно-два улучшения на следующий спринт
Это безопасное пространство. Никто не винит — все хотят расти.
Как это работает на практике?
Допустим, команда в банке разрабатывает функцию оплаты по QR-коду.
- Планирование: продукт-овнер ставит задачу. Команда берёт её на спринт.
- Разработка и тестирование: разработчики пишут код, вы тестируете на эмуляторах, как учили ранее.
- Дейли-стенд: каждый день вы говорите: «Вчера проверил сканирование, сегодня тестирую оплату».
- Ревью: показываете, что сканирование работает, но при оплате зависает экран.
- Ретроспектива: команда решает: «В следующий раз будем тестировать на слабых устройствах с первого дня».
Обратите внимание: вы участвуете на всех этапах, а не только в конце. Это и есть сила Scrum.
Проверьте себя
Кейс: В середине спринта клиент срочно просит изменить приоритет: срочно нужна смена пароля, а не история покупок.
Кто должен принять решение?
- ✅ Продукт-овнер — он отвечает за приоритеты
- ❌ Скрам-мастер — он не решает, что делать
- ❌ Разработчик — он выполняет, а не управляет бэклогом
Вопрос: Каждое утро вы пишете в чат: «Вчера тестировал форму регистрации, сегодня начну тестирование входа по SMS. Проблем нет».
Что это за практика?
- ✅ Дейли-стенд (в асинхронном формате)
- ❌ Отчёт руководителю
- ❌ Планирование спринта
Что дальше?
Теперь вы знаете, как устроен Scrum, кто за что отвечает и как проходит спринт. Вы понимаете, что работающий продукт важнее идеального плана, а команда — это не разработчики, а все вместе.
На следующей странице мы разберём, как именно вы, как тестировщик, включаетесь в эту систему. Где вы участвуете, когда начинаете тестировать, как взаимодействуете с продукт-овнером и скрам-мастером.
Это не теория — это то, с чем вы столкнётесь на первой работе. И чем лучше вы это поймёте, тем увереннее будете чувствовать себя в команде.