Приведи пример дефекта с низким Priority и высоким Severity

Пример дефекта с низким Priority и высоким Severity

В управлении дефектами в тестировании software два ключевых атрибута — Severity (серьезность) и Priority (приоритет) — часто используются вместе, но означают разные вещи. Severity отражает степень негативного воздействия дефекта на систему или пользователя (например, критическая ошибка, приводящая к потере данных). Priority указывает на очередность исправления дефекта в рамках разработки и релизного планирования (например, ошибка должна быть исправлена немедленно или может быть отложена).

Дефект с низким Priority и высоким Severity — это ситуация, когда ошибка имеет серьезное воздействие на функциональность или безопасность системы, но при этом не требует немедленного исправления в текущем цикле разработки. Это происходит из-за контекста: ошибка возникает в редких, специфических условиях, которые маловероятны для основной массы пользователей, или затрагивает функциональность, которая используется очень редко.

Конкретный пример: Банковское приложение

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

• Дефект: При попытке перевода крупной суммы денег (например, более 100 000 долларов) через определенный, редко используемый интерфейс "Перевод по реквизитам в иностранный банк" система завершает транзакцию, но в журнале аудита и в базе данных сохраняется неверная дата операции — вместо текущей даты записывается 01.01.1970. Сама сумма переводится корректно, получатель получает деньги, баланс пользователя обновляется правильно. Однако все связанные отчеты, выписки и аудит показывают неверную дату.

Анализ атрибутов дефекта:

1. Высокая Severity (Серьезность):

    *   **Влияние на бизнес:** Дата — критически важный атрибут для финансовых операций. Ошибка нарушает **аудит**, **отчетность** (включая юридическую и налоговую), **историческую точность данных**.
    *   **Влияние на пользователя:** Клиент может получить выписку с неверной датой, что вызывает недоверие к банку, проблемы при подтверждении операций для третьих лиц (например, налоговых органов).
    *   Тип Severity здесь можно классифицировать как **Critical** или **High**, поскольку ошибка затрагивает **корректность ключевых данных** (data corruption) в критичной для бизнеса области.

1. Низкий Priority (Приоритет):

    *   **Условие возникновения:** Дефект проявляется **только** при переводе сумм выше 100 000 долларов через **очень специфический и редко используемый** платежный канал. Статистика показывает, что такой перевод совершает менее 0.1% пользователей раз в месяц.
    *   **Отсутствие блокировки основного функционала:** Основные функции приложения — просмотр баланса, стандартные переводы, платежи — работают идеально. Переводы меньших сумм или через другие каналы не имеют проблемы.
    *   **Контекст разработки:** Команда находится в финальной стадии подготовки к релизу **нового критичного функционала** — мобильного приложения. Все ресурсы сосредоточены на этой задаче.
    *   **Риск:** Несмотря на серьезность, вероятность столкновения массового пользователя с дефектом в ближайшее время крайне низка. Поэтому менеджмент продукта и разработки принимает решение **отложить исправление** до следующего цикла обновлений, сосредоточившись на задачах с более широким и немедленным воздействием (высоким Priority).

Формальное описание дефекта (Bug Report)

**Title:** [Critical Data Corruption] Incorrect transaction date (01.01.1970) recorded for high-value transfers via 'International Wire Transfer' channel.

**Severity:** Critical
**Priority:** Low

**Steps to Reproduce:**
1. Log in to the banking web app as a user with an account balance > $100,000.
2. Navigate to 'Transfers' -> 'International Wire Transfer'.
3. Initiate a transfer to a valid foreign bank account for an amount > $100,000 (e.g., $150,000).
4. Complete the transaction using valid credentials.

**Expected Result:**
The transaction completes successfully, and the correct current date (e.g., 2024-05-17) is recorded in all systems: audit log, database, user statement.

**Actual Result:**
The transaction completes successfully, funds are transferred correctly. However, the date recorded in the audit log (`transaction_date` field), the core banking database (`operations` table), and subsequently in the user's statement is **01.01.1970**.

**Impact:**
- Corruption of critical financial data (date).
- Breaks audit compliance and reporting accuracy.
- Causes user confusion and distrust for affected (rare) transactions.

**Notes:**
- Defect occurs ONLY under the combination: amount > $100,000 AND 'International Wire Transfer' channel.
- All other transfer types (internal, standard wire) work correctly.
- Functional impact (money movement) is nil, but data integrity impact is severe.
- Due to extremely low occurrence rate ( < 0.1% of monthly transactions) and current focus on mobile app launch, priority is set to Low. Fix scheduled for next development sprint.

Почему это важный пример для QA Engineer

• Контекстное мышление: Тестировщик должен не только находить ошибки, но и оценивать их реальное воздействие в контексте продукта, пользовательской базы и бизнес-целей. Этот пример показывает, что технически серьезная ошибка может быть низкоприоритетной из-за специфики использования.
• Коммуникация с командой: При отчете о таком дефекте QA должен четко объяснить, почему Severity высокая (нарушение аудита, данных), но также предоставить данные или логи о редкой встречаемости, чтобы аргументировать низкий Priority. Это помогает менеджменту принимать взвешенные решения.
• Баланс рисков: Разработка всегда связана с компромиссами. Понимание таких дефектов помогает тестировщику участвовать в процессе управления рисками, предлагая, например, временные решения (например, ручную корректировку отчетов для редких случаев) пока дефект не исправлен в коде.