Ответ
На последнем проекте по тестированию fintech-приложения мы использовали гибридную модель ScrumBan (Scrum + Kanban). Это давало структуру от Scrum и гибкость от Kanban, что было критически важно для работы QA в условиях часто меняющихся приоритетов.
Как это выглядело на практике для QA-команды:
-
Спринты (Scrum): Двухнедельные итерации с фиксированными целями (Sprint Goals). Мы участвовали в:
- Планировании спринта: Оценка тестовой нагруженности новых фич, определение необходимого объема регрессионного тестирования.
- Ежедневных стендапах: Отчитывался о прогрессе (например: "Вчера автоматизировал 3 API-кейса для модуля платежей, сегодня займусь интеграцией их в CI и начну exploratory-тестирование новой формы").
- Ретроспективе: Обсуждали, что улучшить в процессах тестирования (например, "Ускорить прогон smoke-тестов с 20 до 10 минут").
-
Kanban-доска (в Jira): Наш основной рабочий инструмент. Колонки отражали статус задач по тестированию:
Backlog -> Ready for Test -> In Testing (Manual) -> In Testing (Auto) -> Blocked -> Done (Verified)WIP-лимиты (Work In Progress) не позволяли нам брать слишком много задач одновременно, что повышало фокус и скорость прохождения.
-
Процесс тестирования новой фичи:
- Участие в refinement: Я задавал уточняющие вопросы разработчикам и продакт-менеджеру, чтобы сразу выявить риски и написать чек-лист.
- Тестирование в Feature-ветке: Как только разработчик создавал Pull Request, я запускал в CI пайплайн, который:
- Собирал приложение из этой ветки.
- Запускал на нём все релевантные автотесты (юнит, интеграционные, сквозные).
- Разворачивал временное окружение для ручного exploratory-тестирования.
- Приёмка: После успешного тестирования и исправления багов я перемещал задачу в "Done (Verified)" и теггировал её в Jira как
tested-by-{my-name}, что было сигналом для мержа PR.
-
Регрессионное тестирование: Мы не делали «большой регресс» в конце спринта. Вместо этого у нас был набор автоматизированных smoke и regression-тестов, который запускался после каждого успешного мержа в основную ветку. Это давало быструю обратную связь. Раз в месяц я проводил сессию риск-ориентированного ручного регресса на наиболее критичных модулях.
Результат для QA: Мы перестали быть «бутылочным горлышком» в конце спринта. Тестирование было непрерывным и встроенным в процесс разработки, что значительно повысило качество релизов.