Приведи пример urgent Priority

Пример Urgent Priority в работе QA Engineer

Urgent Priority (или критический приоритет) — это категория дефектов, которые требуют немедленного исправления, так как они блокируют ключевую функциональность, нарушают базовые требования или представляют серьёзный риск для безопасности, стабильности или бизнеса.

Критерии для присвоения Urgent Priority

Обычно дефект считается Urgent, если он соответствует хотя бы одному из следующих критериев:

• Полный сбой системы или приложения (например, невозможность запустить приложение, зависание, "падение" с фатальной ошибкой).
• Блокировка основного сценария использования (например, пользователь не может оформить покупку в интернет-магазине).
• Угроза безопасности данных (например, утечка персональной информации, данных кредитных карт).
• Нарушение целостности данных (потеря, необратимая порча критических данных).
• Проблема, затрагивающая всех или подавляющее большинство пользователей в production-среде.

Пример сценария и баг-репорта

Сценарий: Финансовое приложение для переводов между пользователями. Основной поток: пользователь авторизуется, выбирает получателя, вводит сумму и подтверждает перевод.

Шаги для воспроизведения:

1. Войти в приложение под валидной учётной записью.
2. На главном экране нажать кнопку "Новый перевод".
3. Выбрать любого получателя из списка контактов.
4. В поле "Сумма" ввести 0 (ноль).
5. Нажать кнопку "Подтвердить".

Ожидаемый результат: Приложение отображает валидационное сообщение "Сумма перевода должна быть больше 0" и не позволяет отправить перевод.

Фактический результат: Приложение выполняет SQL-запрос на списание средств, в базе данных сумма у отправителя меняется на баланс - 0, у получателя — на баланс + 0. На экране появляется уведомление "Перевод на сумму 0 успешно выполнен". Фактически перевод не произошёл, но операция записана в историю транзакций.

Описание проблемы:

Это критический (Urgent) дефект, потому что он нарушает фундаментальную бизнес-логику и целостность данных:

• Бизнес-логика: Перевод нулевой суммы финансово бессмыслен и не должен быть возможен.
• Целостность данных: В историю транзакций пишется "мусорная" запись, которая искажает отчётность, логи аудита и может привести к ошибкам в расчётах (например, при подсчёте комиссий или в аналитических отчётах).
• Риск эксплуатации: Этим могут злоупотреблять. Например, автоматизированный скрипт может создать тысячи таких "пустых" транзакций, засорив базу данных и вызвав проблемы с производительностью.
• Доверие пользователей: Система, позволяющая совершать абсурдные операции, подрывает доверие к её надёжности.

Баг-репорт с Urgent Priority:

Заголовок: [URGENT] Приложение позволяет выполнить и записать в историю перевод с нулевой суммой

Серьёзность (Severity): Critical
Приоритет (Priority): Urgent/P0

Окружение:
*   Приложение: MoneyTransfer v2.1.0
*   ОС: Android 14 / iOS 17
*   Серверная версия: backend-release-45

Шаги воспроизведения:
1. Авторизоваться в приложении.
2. Нажать "Новый перевод".
3. Выбрать получателя.
4. В поле "Сумма" ввести "0".
5. Нажать "Подтвердить".

Ожидаемый результат:
- Появляется ошибка валидации.
- Запрос к серверу не отправляется.
- Балансы и история транзакций не изменяются.

Фактический результат:
- Появляется уведомление об успешном переводе 0.
- В истории транзакций отправителя и получателя появляется новая запись о переводе 0.
- Логи сервера показывают выполнение SQL-запросов UPDATE для таблиц `accounts` и `transactions`.

Дополнительная информация:
*   Дефект воспроизводится в 100% случаев.
*   Проблема находится на стороне сервера: отсутствует проверка `amount > 0` перед выполнением бизнес-логики и записью в БД.
*   Логи сервера прилагаются (файл server_logs.txt).
*   Скриншоты: [ссылка на вложение].

Предполагаемая причина:
Отсутствие валидации входных данных для поля "сумма" в эндпоинте `/api/v1/transfer` на стороне сервера. Клиентская валидация также отсутствует.

Процесс работы с Urgent-дефектом

1. Обнаружение и регистрация: QA инженер немедленно создаёт баг-репорт, выставляет Priority: Urgent и уведомляет команду (разработчиков, менеджера проекта, тимлида) через все доступные каналы (чат, email, лично).
2. Триаж: Команда в срочном порядке проводит встречу (триаж). Разработка приостанавливает текущие задачи, если это необходимо.
3. Исправление: Разработчик вносит исправление в приоритетном порядке. Часто требуется хотфикс (горячее исправление).
4. Проверка: После предоставления билда QA инженер в первую очередь проверяет именно этот дефект, а также проводит анализ смежных областей на регрессию, вызванную исправлением.
5. Деплой: Исправление максимально быстро доставляется в production, особенно если дефект обнаружен там.

Такой дефект не может ждать очередного спринта или релиза — он должен быть устранён в течение нескольких часов или одного рабочего дня, так как его существование наносит прямой ущерб качеству продукта и создаёт системные риски.