Какие знаешь виды Backlog?

Виды Backlog в Agile и Scrum

В контексте Agile и Scrum, Backlog — это центральный инструмент планирования и управления работой. Он представляет собой упорядоченный список всего, что может быть нужно в продукте. Основные виды backlog, с которыми я работаю как QA Engineer:

1. Product Backlog (Продуктовый бэклог)

Это основной и самый высокоуровневый список. Он содержит все возможные требования, функции, улучшения и исправления для продукта. Его владельцем является Product Owner (PO).

• Содержание: Эпики, пользовательские истории, технические задания, баги, задачи по исследованию (spikes).
• Приоритет: PO постоянно пересматривает и упорядочивает элементы, обычно по критериям ценности для бизнеса, затратам и рискам. Самые важные задачи находятся на вершине списка.
• Роль QA: Я активно участвую в его формировании, особенно в части:

    *   Добавления **quality-related задач**: например, "Реализовать автоматизацию тестов для модуля X", "Провести исследование инструментов нагрузочного тестирования".
    *   **Декомпозиции крупных эпиков** на тестируемые пользовательские истории, чтобы критерии приемки (acceptance criteria) были четкими и проверяемыми.
    *   **Оценки сложности** с точки зрения тестирования, что влияет на общую оценку усилий разработки.

Пример элемента Product Backlog:
**Эпик:** Улучшение процесса оплаты.
**История:** Как пользователь, я хочу видеть детализированную сводку перед подтверждением оплаты, чтобы избежать ошибок.
**Критерии приемки (AC):**
1. На экране подтверждения отображается итоговая сумма, список товаров и выбранный способ оплаты.
2. При изменении любого параметра в сводке сумма пересчитывается автоматически.
3. Если сумма не совпадает с ожидаемой, пользователь может вернуться к корзине.
**(Задача QA):** Обеспечить покрытие AC автотестами для UI и API.

2. Sprint Backlog (Бэклог спринта)

Это список задач, выбранных из Product Backlog для выполнения в текущем спринте (итерации). Он создается и owned Scrum Team (разработчики, QA, PO) на планировании спринта.

• Содержание: Конкретные, технически декомпозированные задачи, необходимые для реализации выбранных пользовательских историй. Например: "Разработать API метод для расчета суммы", "Написать модульные тесты для сервиса оплаты", "Создать тестовые сценарии для UI".
• Динамичность: Может немного меняться во время спринта по согласованию команды.
• Роль QA: Мои задачи здесь всегда представлены явно. Я отвечаю за:

    *   Создание задач на **тест-дизайн**, **ручное тестирование**, **автоматизацию** и **регресс**.
    *   **Координацию** с разработчиками: чтобы задачи на тестирование были зависимы от задач на разработку и вовремя взяты в работу.
    *   **Отслеживание прогресса** по тестовым задачам через ежедневные Scrum встречи.

3. Bug Backlog (Бэклог дефектов)

Часто это подвид или отдельный фильтр внутри Product Backlog, куда попадают все обнаруженные баги. Управление им — ключевая область ответственности QA.

• Принципы: В идеальном Agile баги не имеют отдельного жизненного цикла. Серьезные баги, блокирующие выпуск, могут попасть в Sprint Backlog текущего или даже следующего спринта. Менее важные баги попадают в Product Backlog и оцениваются PO по ценности/риску наравне с новыми функциями.
• Практика: В реальности часто существует отдельный список или борд (например, в Jira) для багов, который QA и PO регулярно трижают:

    *   **Приоритизация** по severity (критичность) и priority (важность для бизнеса).
    *   **Уточнение и верификация** перед передачей разработчикам.
    *   **Очистка**: закрытие дубликатов, нерелевантных или невоспроизводимых багов.

# Пример логики приоритизации бага (условный код)
def prioritize_bug(severity, business_impact, frequency):
    if severity == 'Critical' and business_impact == 'High':
        return 'Fix in current sprint'
    elif severity == 'Major' and frequency == 'High':
        return 'Add to top of Product Backlog'
    else:
        return 'Review next PO meeting'

4. Technical / Improvement Backlog (Технический бэклог)

Это список ненаправленных на пользователя задач, необходимых для поддержания здоровья проекта: рефакторинг, обновление библиотек, улучшение инфраструктуры CI/CD, техническое исследование.

• Важность для QA: Здесь лежат задачи, критичные для обеспечения качества:

    *   **Улучшение тестовой инфраструктуры:** "Перейти на новую версию Selenium", "Настроить параллельный запуск тестов".
    *   **Технический долг тестирования:** "Добавить моки для тестов API", "Рефакторинг нестабильных автотестов".
    *   **Работа с данными и окружением:** "Создать скрипты для генерации тестовых данных", "Автоматизировать развертывание тестового стенда".

5. Release Backlog (Бэклог релиза)

Не всегда формализован. Это подмножество Product Backlog, которое PO и команда определяют как цель для конкретного релиза (который может состоять из нескольких спринтов). QA участвует в его формировании, чтобы убедиться, что для всего запланированного на релиз есть:

• Достаточное время для всех видов тестирования.
• Четкие критерии готовности (release criteria), включая качество.
• План тестирования (test plan) и стратегия (test strategy).

Как QA Engineer, я не просто "потребляю" backlog, я активно влияю на все его виды. Моя задача — внедрять требования качества в каждый элемент, обеспечивать, что тестирование не является "сюрпризом" в конце спринта, и что backlog всегда отражает реальную работу, необходимую для создания надежного продукта. Это включает в себя добавление тестовых задач, прояснение критериев приемки и постоянную коммуникацию с PO и разработчиками о приоритетах и рисках, связанных с качеством.