Найти в Дзене

Что делать, если вы нашли баг — но никто не считает его багом?

Вы только начинаете карьеру в тестировании. Нашли баг, тщательно описали его, отправили в баг-трекер…
А в ответ — тишина. Или, что бывает обиднее: «Это не баг, это фича».
«Так и было задумано».
«Пользователю всё равно».
«Починим потом, сейчас не до этого». Что делать? Ошибка ведь реальная. Но никто, кажется, не хочет её признавать.
Разбираемся, как действовать в таких ситуациях — и не терять мотивацию.
Иногда багом может показаться то, что работает по специфике бизнес-логики.
Перед тем как создавать тикет, стоит: Ваш баг должен быть обоснован, а не просто «по ощущениям что-то не так». Даже серьёзный дефект могут проигнорировать, если он оформлен неструктурированно.
Что стоит указать: Чем понятнее баг — тем больше шансов, что его примут. Если баг посчитали неважным, важно не спорить, а объяснить: «Сейчас кнопка “Удалить” ничего не делает — при этом нет никакой реакции. Пользователь может подумать, что система зависла.» Старайтесь говорить от лица пользователя. Это работает луч
Оглавление

Вы только начинаете карьеру в тестировании. Нашли баг, тщательно описали его, отправили в баг-трекер…

А в ответ — тишина. Или, что бывает обиднее:

«Это не баг, это фича».

«Так и было задумано».

«Пользователю всё равно».

«Починим потом, сейчас не до этого».

Что делать? Ошибка ведь реальная. Но никто, кажется, не хочет её признавать.

Разбираемся, как действовать в таких ситуациях — и не терять мотивацию.

1️⃣ Убедитесь, что вы точно поняли, как должен работать функционал

Иногда багом может показаться то, что работает по специфике бизнес-логики.

Перед тем как создавать тикет, стоит:

  • 📌 Ознакомиться с задачей или техническим заданием
  • 🔍 Проверить макеты, если они есть
  • ❓ Задать уточняющие вопросы аналитику, тимлиду или продакт-менеджеру

Ваш баг должен быть обоснован, а не просто «по ощущениям что-то не так».

2️⃣ Сформулируйте баг грамотно

Даже серьёзный дефект могут проигнорировать, если он оформлен неструктурированно.

Что стоит указать:

  • Чёткое и понятное название
  • Пошаговая инструкция: как воспроизвести
  • Фактически и ожидаемый результаты
  • Скриншоты или видео
  • Влияние на пользователя: влияет ли на бизнес-логику, вызывает ли фрустрацию или потерю данных

Чем понятнее баг — тем больше шансов, что его примут.

3️⃣ Аргументируйте спокойно

Если баг посчитали неважным, важно не спорить, а объяснить:

«Сейчас кнопка “Удалить” ничего не делает — при этом нет никакой реакции. Пользователь может подумать, что система зависла.»

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

4️⃣ Будьте готовы к тому, что баг всё равно отклонят

Это часть профессии. Не все баги попадают в релиз — у команды могут быть приоритеты, ограничения по срокам или иное видение.

❗️Но даже если баг отклоняют, вы:

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

💡 Важно запомнить:

  • Всегда уточняйте, как должно работать — не гадайте
  • Описывайте баги чётко и структурированно
  • Аргументируйте спокойно и по существу
  • Уважайте решение команды, даже если с ним не согласны