Приведи примеры бага Priority

Примеры багов с разным уровнем Priority

Priority (Приоритет) в тестировании определяет очередность исправления дефекта. Вот классические примеры для каждого уровня приоритета.

High Priority (Высокий)

Эти баги блокируют критически важный функционал, не позволяя завершить ключевые сценарии использования.

• Ошибка при создании учетной записи: Кнопка "Зарегистрироваться" на форме регистрации неактивна или вызывает 500 Internal Server Error.

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

• Ошибка оплаты в интернет-магазине: На этапе подтверждения заказа система выдает ошибку "Не удалось обработать платеж" при использовании любого способа оплаты.

    *   **Сценарий:** Ни один покупатель не может совершить покупку. Прямая потеря выручки.

• Крах приложения при запуске: Мобильное приложение закрывается с ошибкой сразу после запуска на поддерживаемой версии ОС.

    *   **Сценарий:** Ни один пользователь не может войти в приложение. Полная неработоспособность.

Medium Priority (Средний)

Дефекты, которые нарушают важный функционал, но есть временный обходной путь, или проблема не блокирует основные операции.

• Некорректная валидация в поле email: Форма принимает email-адрес без символа "@" (например, userexample.com).

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

• Не работает сортировка по цене в каталоге: В списке товаров кнопки сортировки "От дешевых к дорогим" и "От дорогих к дешевым" меняют порядок произвольно.

    *   **Сценарий:** Пользователь может найти нужный товар через поиск или фильтры, но ключевая функция навигации нарушена.

• Опечатка в критическом сообщении об ошибке: В сообщении "Не удалось сохранить файл, проверьте права доступа" допущена грубая орфографическая ошибка, которая искажает смысл ("права одступа").

    *   **Сценарий:** Функционал сохранения работает, сообщение показывает, но подрывает доверие к качеству продукта.

Low Priority (Низкий)

Незначительные дефекты, не влияющие на основную бизнес-логику. Часто это косметические или UX-проблемы.

• Неверный оттенок серого цвета у неактивной кнопки: Цвет кнопки отличается от утвержденного в гайдлайнах дизайна на 5%.

    *   **Сценарий:** Функционально все работает корректно, внешний вид почти не отличается. Влияет только на строгое соответствие дизайну.

• Опечатка в тексте всплывающей подсказки (tooltip): В подсказке к иконке "Сохранить" написано "Сохранить изминения".

    *   **Сценарий:** Функция сохранения работает идеально. Ошибка малозаметна и не мешает использованию.

• Неидеальное выравнивание элементов на странице, не видимое без увеличения: В таблице заголовок колонки смещен на 2 пикселя вправо относительно данных в столбце.

    *   **Сценарий:** Подавляющее большинство пользователей не заметит дефект. Он не влияет на чтение данных или кликабельность.

Важный нюанс: Priority vs Severity

Пример, иллюстрирующий разницу между Severity (Серьезность/Критичность) — влияние на систему, и Priority (Приоритет) — срочность исправления.

• Баг:

    *   **Severity = High (Критичный).** На главной странице публичного сайта в футере (подвале) отображается ссылка, ведущая на страницу конфигураций для администраторов системы (например, `/admin/config`). Это утечка информации об устройстве системы.
    *   **Priority = Low (Низкий).** Ссылка видна только в футере, не бросается в глаза, не мешает работе основного функционала для 99.9% пользователей. Исправление может быть отложено до следующего спринта.

**Резюме по приоритетам:**

*   **High (P1):** "Нужно исправить вчера". Блокирует бизнес, ведет к прямым потерям.
*   **Medium (P2):** "Нужно исправить в этом спринте/релизе". Существенная помеха, но с обходным путем.
*   **Low (P3):** "Исправим, когда будет время". Косметические проблемы, не влияющие на выполнение задач.

Решение о финальном приоритете бага всегда принимается командой (QA, разработчик, менеджер продукта) на основе его Severity, бизнес-контекста, стадии разработки и дорожной карты релизов. Один и тот же по сути баг (например, падение приложения) может иметь High Priority на продакшене, но Medium на стадии альфа-тестирования.