Как будешь распределять приоритетность задач

Стратегия распределения приоритетности задач в QA

Базовая матрица приоритизации

Использую комбинацию: Impact (влияние) × Urgency (срочность), дополненную анализом Risk (риск).

Четыре квадранта приоритизации

Квадрант 1: Критичные (Critical) — ДЕЛАТЬ ПЕРВЫМ

• High Impact + High Urgency
• Production issues (приложение не работает)
• Security vulnerabilities (взлом, утечка данных)
• Payment failures (денежные операции не проходят)
• Major crashes и data corruption

Пример: Payment API вернул ошибку — пользователи не могут купить. Это CRITICAL.

Квадрант 2: Важные (Important) — ПЛАНИРОВАТЬ СИСТЕМАТИЧЕСКИ

• High Impact + Low Urgency
• Новые фичи для тестирования
• Regression testing перед релизом
• Performance optimization
• Security improvements (не критичные)

Пример: Завтра релиз новой версии — нужно полное регрессионное тестирование.

Квадрант 3: Срочные мелочи (Urgent But Not Important)

• Low Impact + High Urgency
• Запросы stakeholders на small fixes
• Cosmetic bugs (неправильный цвет)
• Низкий уровень, но срочно

Пример: CEO увидел неправильный spacing. Срочно для него, но влияния нет.

Квадрант 4: Фоновые задачи (Low Priority)

• Low Impact + Low Urgency
• Улучшение документации
• Рефакторинг старых тестов
• Оптимизация процессов
• Nice-to-have improvements

Дополнительный фактор: Risk-Based Prioritization

Риск = Вероятность × Влияние

Пример функции удаления учетной записи:

• Вероятность бага: High (сложная логика)
• Влияние: Critical (потеря всех данных)
• Риск = High → тестируем тщательно

Метод MoSCoW (для спринтов)

• Must: Критично для релиза (payment, security, crashes)
• Should: Важно, но не критично (regression, new features)
• Could: Nice-to-have (UI improvements, performance)
• Won't: Не делаем в текущем спринте (tech debt, cosmetic)

Процесс приоритизации

Шаг 1: Сбор информации

• Что сломалось?
• Какой процент пользователей затронут?
• Влияет ли на критичные пути?
• Когда это нужно?

Шаг 2: Консультация со stakeholders

• Разработчик: когда будет готово?
• Product Manager: насколько важно?
• DevOps: можем ли откатить?

Шаг 3: Техническая оценка

• Сколько времени на тестирование?
• Какой инструмент нужен?
• Есть ли существующие тесты?

Шаг 4: Решение

• Тестирую и баг-репортю
• Или откладываю на позже

Практические примеры

Сценарий 1: Payment gateway сбой Impact: Critical | Urgency: Critical | Risk: Critical Решение: Останавливаю всё, помогаю разработчикам

Сценарий 2: Новая фича перед релизом Impact: High | Urgency: High | Risk: High Решение: Основное тестирование, потом критичные пути

Сценарий 3: UI bug в админ-панели Impact: Low | Urgency: Medium | Risk: Low Решение: Документирую, бэклог, делаю в следующем спринте

Сценарий 4: Оптимизация test suite Impact: Medium | Urgency: Low | Risk: Medium Решение: Планирую, когда меньше срочных задач

Key принципы

• Думаю о бизнесе: как это влияет на revenue?
• Общаюсь с командой: не решаю в вакууме
• Переоцениваю регулярно: приоритеты меняются
• Выделяю время на техдолг: 20% на улучшения
• Умею сказать нет: low priority = аргументирую почему