Какие знаешь статуты задач на проекте?

Статусы задач в проектах разработки ПО

В управлении проектами, особенно в области QA (Quality Assurance), четкое понимание и использование системы статусов задач (таск-статусов) является критически важным для организации работы, транспарентности процесса и эффективного контроля качества. Статусы задач — это метки, которые отражают текущее состояние работы по конкретной задаче (баг-репорт, фича, улучшение) в рамках жизненного цикла.

Как опытный QA Engineer, я работал с различными системами (Jira, Trello, Asana, GitHub Issues, внутренние системы) и видел как стандартные, так и кастомные наборы статусов. Основной набор можно разделить на несколько ключевых групп.

Основные (базовые) статусы задач

Это наиболее распространенные статусы, которые встречаются в большинстве проектов.

• Open / New / To Do: Задача создана, описана и находится в очереди для выполнения. Это начальный статус.
• In Progress / Active: Задача взята в работу конкретным исполнителем (разработчиком, QA). Например, разработчик начал писать код для фичи, или QA начал тестирование бага.
• Resolved / Fixed / Done (Development): Исполнитель (чаще разработчик) сообщает, что техническая часть работы выполнена. Для бага — код исправлен и закоммичен; для фичи — функционал реализован. Это ключевой момент для QA! Задача переходит в статус, требующий верификации (проверки).
• Closed / Verified: После статуса Resolved QA Engineer проводит регрессионное тестирование и, если все условия выполнены (баг исправлен, фича работает согласно требованиям), закрывает задачу. Статус Closed означает окончательное завершение.
• Reopened: Если при верификации (Resolved -> Closed) QA обнаруживает, что проблема не решена полностью, появляется новый связанный баг или функционал работает неверно, задача возвращается в работу (Reopened -> In Progress). Это важный статус для контроля качества.
• Blocked / On Hold: Задача временно не может быть выполнена из-за внешних факторов: зависимости от другой задачи, отсутствия информации, технических ограничений. Используется для избежания "застревания" задач в In Progress.

Специфичные статусы для QA и тестирования

В процессах, где тестирование выделено в отдельные этапы, используются дополнительные статусы.

• Ready for Test / QA In Progress: Задача (фича или исправленный баг) передана в тестирование и ожидает или уже находится в работе QA-инженера. Часто является переходным между Resolved (от dev) и Closed (от QA).
• Testing / Under Verification: Конкретный статус, указывающий, что QA активно проводит тестирование.
• Failed QA / Needs Revision: Альтернатива Reopened, более явно указывающая, что верификация не прошла и требуется исправление от разработки.

Статусы для планирования и приоритизации

Эти статусы часто используются на этапах планирования (бэклог) до того, как задача попадает в активную работу.

• Backlog: Задача запланирована, но не назначена на конкретный спринт или период разработки.
• Selected for Development / Ready for Sprint: Задача выбрана для включения в следующий цикл разработки (спринт).

Пример workflow (жизненного цикла) задачи в Jira

Рассмотрим типичный путь баг-репорта от создания до закрытия в системе Jira, которой пользуются множество команд.

# Пример конфигурации workflow для бага в Jira (схематично)
Bug Lifecycle:
  1. Open -> (Assignee picks up task) -> In Progress
  2. In Progress -> (Developer fixes bug) -> Resolved
  3. Resolved -> (QA starts verification) -> QA In Progress
  4. QA In Progress -> (QA confirms fix) -> Closed
  5. QA In Progress -> (QA finds issue) -> Reopened
  6. Reopened -> (Back to developer) -> In Progress

Почему важно правильно использовать статусы?

• Визуализация прогресса: Доски (Kanban, Scrum board) дают мгновенное представление о состоянии проекта.
• Автоматизация отчетов: Статусы — основа для метрик (velocity, burndown charts).
• Четкое разделение ответственности: Статус Resolved — ответственность Dev, статус Closed — ответственность QA.
• Управление блокировками: Статус Blocked помогает выявить и решить системные проблемы.

На сложных проектах (например, с несколькими этапами тестирования: smoke, регресс, acceptance) могут появиться кастомные статусы (Passed Smoke, Ready for UAT). Главное — чтобы система статусов была простой, понятной для всей команды и отражала реальный процесс работы. Недостаток статусов приводит к хаосу, избыток — к бюрократии. Идеальный набор — минимально необходимый для четкого отслеживания каждой задачи от создания до финального разрешения.