По каким причинам разработчик может отклонить дефект

Причины отклонения дефектов разработчиком

Это одна из самых частых и фрустрирующих ситуаций в QA работе. За 10+ лет я столкнулся с сотнями отклоненных дефектов и научился понимать, когда разработчик прав, а когда это просто защита. Расскажу о типичных причинах и как на них реагировать.

Типичные причины отклонения

1. "Это не баг, это по дизайну"

Это САМАЯ частая причина отклонения.

Примеры:

• "Кнопка серая потому что это disabled состояние" (по дизайну)
• "После добавления товара нет скролла наверх" (может быть по требованиям)
• "Фильтр не сохраняется при перезагрузке" (может быть намерено)

Мой подход:

1. Спросить: "Где это задокументировано?" (требования, дизайн, user story)
2. Проверить документацию самостоятельно
3. Если нет документации → escalate на PM
4. Если есть документация, подтверждающая мою правоту → переоткрыть дефект

Реальный пример: Обнаружил, что при нажатии "Buy" кнопка не меняет свой вид (например, не становится disabled).

Разработчик отклонил: "Это по дизайну, мы не хотим менять вид"

Мой ответ: "Дизайнер согласен, что это важно для UX (пользователь видит, что нажал)? Давай проверим дизайн в Figma"

После проверки Figma: Дизайнер согласился, что кнопка должна меняться. Разработчик исправил.

2. "Это user error, не баг в коде"

Разработчик говорит: пользователь делает что-то неправильно.

Примеры:

• "Пользователь вводит неправильный формат email" → приложение падает

  • Dev: "Это user error, пользователь ввел неправильно"
  • QA: "Приложение должно валидировать и показывать ошибку, не падать!"

• "Пользователь кликает так быстро, что двойной платеж"

  • Dev: "Это user error, пользователь не должен кликать дважды"
  • QA: "Приложение должно защищать от double-click'а!"

Мой подход:

Я согласен, это user error. НО: приложение должно elegantly обрабатывать user error'ы:

• Показать понятное сообщение об ошибке
• Не падать
• Не потерять данные
• Не создавать глюки

Возражение разработчику: "Я согласен, это user error. Но приложение должно защищать себя от такого ввода. Давайте добавим валидацию/double-click protection."

3. "Это очень редкий edge case"

Разработчик говорит: это происходит в 0.1% случаев.

Примеры:

• "Это происходит только при комбинации: iOS 12 + iPhone SE + медленная сеть"
• "Это только если пользователь откроет 100 вкладок одновременно"
• "Это только если отключить JavaScript"

Мой подход:

Зависит от severity:

Если Critical: "Неважно, 0.1% это или 50%, если приложение падает → нужно чинить"

Если Medium/Low: "Я согласен, это редко. Можем отложить на next sprint, но задокументируем как known issue"

Реальный пример: Обнаружил, что при использовании VPN + медленной сети (3G) видео не загружается.

Dev: "Только 1% пользователей использует VPN и медленную сеть одновременно"

Мой ответ: "Может быть 1%, но для тех пользователей приложение нерабочее. Давайте:

• Либо чинить (показывать понятное сообщение вместо hang)
• Либо документировать: 'Known issue: медленная сеть + VPN'"

4. "Это баг в браузере/ОС, не в нашем коде"

Примеры:

• "Safari имеет проблему с CSS grid" (баг Safari)
• "Android 9 не поддерживает WebSocket правильно" (баг Android)
• "iOS 13 падает при определенной работе памяти" (баг iOS)

Мой подход:

Разработчик может быть прав! Но это все равно проблема для пользователей:

1. Проверить: действительно ли это баг браузера/ОС?

   • Попробовать на чистом браузере
   • Найти issue в Chrome/Safari/Firefox tracker'е
   • Проверить StackOverflow

2. Если да: "Я согласен, это баг браузера. Но нам нужно:

   • Добавить workaround (если есть)
   • Документировать: 'Known issue: не работает на Safari XXX'
   • Мониторить, может быть браузер исправит"

3. Если нет: Переоткрыть дефект.

5. "Это не воспроизводится"

Разработчик говорит: он не смог воспроизвести баг.

Примеры:

• "Я добавлял товар много раз, не воспроизводится"
• "Я не вижу эту ошибку на моей машине"
• "Может быть это проблема с окружением?"

Мой подход:

1. Дать максимально детальный баг report:

   • Точные шаги
   • Environment (браузер, версия, ОС)
   • Expected vs. Actual
   • Screenshot/видео
   • Logs если есть

2. Предложить помощь:

   • "Давай воспроизведим вместе на call"
   • "Вот видео как это воспроизводится"
   • "Проверь эти конкретные условия"

3. Если все равно не воспроизводится:

   • Может быть это intermittent баг
   • Нужно добавить мониторинг/логирование
   • Оставить дефект открытым, мониторить

Реальный пример: Обнаружил, что в 50% случаев при оплате товара приходит ошибка "Payment timeout". Dev не воспроизводил.

Мой подход:

• Собрал 5 видео где это воспроизводится
• Проверил logs: действительно есть timeout errors
• Показал Dev'у logs
• Dev нашел, что API работает медленнее чем ожидается
• Увеличили timeout

6. "Это конфликт зависимостей"

Pримеры:

• "Это конфликтует с requirement'ом X"
• "Если чинить это, то сломается feature Y"
• "Это требует изменения в database schema"

Мой подход:

1. Согласиться: "Да, это может быть сложно"

2. Спросить: "Как мы решаем это?"

3. Предложить варианты:

   • Чинить (стоит ли оно того?)
   • Отложить (на когда?)
   • Workaround (есть ли вариант?)
   • Документировать как known issue

4. Escalate на техлида/PM для prioritization

7. "Это требует большой переделки"

Разработчик говорит: дефект требует 10 часов работы.

Примеры:

• "Для чинки нужно переписать логику авторизации"
• "Нужно миграция базы данных"
• "Нужно менять API контракт"

Мой подход:

1. Прислушаться: может быть разработчик прав

2. Оценить severity баги:

   • Если Critical (блокирует функционал) → нужно чинить, несмотря на complexity
   • Если High (серьезная проблема) → оценить ROI (стоит ли 10 часов?)
   • Если Medium (неприятно, но work around существует) → отложить
   • Если Low (минорная) → отложить

3. Escalate для принятия решения

8. "Это требование было неясным"

Разработчик говорит: он реализовал по лучшему пониманию требования.

Примеры:

• "Requirement говорит 'показать товары', я показал все, не отфильтрованные"
• "Requirement молчит о том, как обрабатывать ошибку API"

Мой подход:

1. Это красный флаг → требования были неясные
2. Не винить разработчика
3. Уточнить requirement вместе с PM/Design
4. Если требование ясно, что мы хотели → разработчик должен исправить
5. Если требование было действительно неясным → это failure планирования, учитесь на будущее

9. "Это не соответствует нашей архитектуре"

Разработчик говорит: фикс нарушит design pattern'ы.

Примеры:

• "Для чинки нужно добавить boolean флаг, это нарушит чистоту кода"
• "Это потребует изменения в API contract, что сломает других клиентов"

Мой подход:

1. Спросить: "Есть ли лучший способ?"
2. Уважать архитектурные решения
3. Но: "Если это баг, нам нужно его чинить" (даже если неэлегантно)
4. Предложить: "Может быть чинить now + рефакторить later?"

10. "Это был временный workaround, не final решение"

Разработчик говорит: это placeholder код.

Примеры:

• "Это временное решение, мы переделаем это на next sprint"
• "Это TODO код, я знаю что нужно улучшить"

Мой подход:

1. Если это работает корректно → Ok, принять
2. Если это имеет неправильное поведение → чинить now
3. Если это технический debt → документировать, отложить на refactoring sprint

Как я реагирую на отклонение дефекта

Шаг 1: Не брать эмоционально

"Дефект отклонен" ≠ "Я плохой QA"

Это нормальная часть процесса. Иногда разработчик прав.

Шаг 2: Изучить причину отклонения

Прочитать комментарий разработчика в дефекте.

Примеры:

• "Это по дизайну" → проверить дизайн
• "Это user error" → согласиться или переоценить
• "Не воспроизводится" → собрать более детальную информацию

Шаг 3: Ответить или переоткрыть

Опция 1: Согласиться с разработчиком
"Ты прав, проверил дизайн, это действительно по дизайну. Закрываю как NOT A BUG."

Опция 2: Предоставить больше информации
"Я согласен, не воспроизводится легко. Вот видео как это воспроизводится."

Опция 3: Переоткрыть дефект
"Я не согласен, потому что [аргумент]. Переоткрываю дефект."

Опция 4: Escalate
"Мы не согласны. Давайте обсудим с техлидом/PM на standup."

Шаг 4: Документировать решение

Для future reference: почему дефект был отклонен?

Как ИЗБЕЖАТЬ отклонения дефектов

1. Хороший баг report

✗ Плохо: "Кнопка не работает" ✓ Хорошо:

Title: Payment button unresponsive after discount code applied

Steps to Reproduce:
1. Go to checkout page
2. Add discount code "SAVE10"
3. Try to click Payment button
4. Button appears disabled (grayed out)

Expected: Button is clickable, payment dialog opens
Actual: Button is disabled, nothing happens

Environment: Chrome 120, Windows 10
Attachment: screenshot, video

2. Проверить дизайн/требования перед тем как логировать баг

Не потратить время обоих на обсуждение очевидных вещей.

3. Быть конкретным

✗ "Это медленно" → что измеряет медленность? ✓ "Загрузка занимает 5 сек, requirement говорит <2 сек"

4. Предложить решение (если есть идея)

"Баг: API возвращает неправильное поле. Предложение: используй поле 'updated_at' вместо 'modified_date'"

5. Быть respectful

Разработчик видит твой bug report ежедневно. Делай его приятным для чтения:

• Ясный, четкий, без нецензурных выражений
• Благодарность за внимание
• Готовность помочь

Итог

Отклонение дефектов — это нормальная часть QA процесса. Главное:

1. Попытайся понять причину — разработчик может быть прав
2. Подготови хороший баг report — уменьши вероятность отклонения
3. Будь respectful — это не личное, это работа
4. Escalate если нужно — техлид/PM помогут решить конфликты
5. Учись — каждое отклонение дефекта учит тебя что-то новое

Мой опыт: 90% отклоненных дефектов имели веские причины. 10% были неправильными отклонениями (которые я переоткрывал с доказательствами). Ключ — хороший баг report и уважительное общение.