Главная дилемма тестировщика

Когда только начинаешь тестировать, кажется, что баг — это когда что-то явно сломалось. Но реальность сложнее: ТЗ может отсутствовать, противоречить себе или просто устареть.

Пример: В интернет-магазине есть сортировка товаров по цене. По задумке — сначала дешёвые. Всё работает. Но когда пользователь выбирает фильтр «только в наличии», сортировка сбрасывается. Технически всё по ТЗ, но это бесит пользователей: каждый раз приходится выбирать сортировку заново. Баг или нет?

Короткий чек-лист для серых зон:

✅Если есть требования — сверяем с ними. Не соответствует? Баг. Соответствует, но написано плохо? Это баг в требованиях, идём к аналитику.

✅Если требований нет — включаем голову:

· Как реализованы аналоги в продукте? Нарушение консистентности = баг. · Что принято в индустрии? Пароль виден открытым текстом — баг безопасности. · Удобно ли пользователю? Если он запутается или потеряет данные — баг.

✅Спор с разработчиком — не переходим на личности. Ищем аргументы: макеты, ТЗ, сценарии, которые ломаются. Не договорились? Зовём тимлида или продакта.

✅Особые случаи — баги бывают не только функциональными. Кнопка работает, но её не видно (юзабилити) — баг. Форма грузится 30 секунд — баг производительности.

Итоговый чек-лист перед заведением задачи:

1. Есть явное несоответствие требованиям? → баг. 2. Нет требований, но нарушена логика, консистентность или ожидания пользователя? → скорее баг. 3. Может привести к ошибкам, потере данных или денег? → точно баг. 4. Просто не нравится лично мне? → возможно, это улучшение, выносим на обсуждение.

А у вас был случай, когда баг оказывался фичей? Делитесь в комментариях 👇

о тестировании в тг https://t.me/testingqabug #знания