Вопросы

«Я всё проверил, должно работать»

Каждый раз, когда я это слышу, я понимаю — моя работа только начинается. Разработчик проверил то, что менял. Я проверяю то, что могло сломаться рядом. Сначала — быстрый smoke по критическим сценариям. Потом — интеграции: API-контракт, данные в БД, связки сервисов. Дальше — соседние модули. Особенно если правки были в shared-коде. И обязательно edge cases: – пустые поля – неожиданные типы данных – сетевые ошибки – поведение при частичном фейле Потому что баги живут не там, где «меняли». Они живут там, где «должно работать». Мало времени? Отлично. Значит, нужно думать. Я прогоняю три фильтра: → Что изменилось — проверяю полностью. → Что критично для бизнеса — платежи, авторизация, данные — всегда. → Что уже ломалось — история багов не врёт. Всё остальное — осознанный риск. И я его проговариваю до релиза. QA не должен молча страдать из-за сроков. Решение выпускать с неполным покрытием — командное. Хороший баг-репорт — это не сочинение. Это инструмент. Чёткие шаги воспроизведения. Ожидаемое vs фактическое. Контекст: окружение, билд, лог. Если разработчик не может повторить баг с первой попытки — это не баг-репорт. Это загадка. А загадки в продакшене никто не любит. За 12 лет в QA я понял простую вещь: Качество — это не про то, чтобы тормозить релиз. И не про то, чтобы «поймать всех». Качество — это снижение неопределённости. Это когда команда выпускается спокойно. И знает, что систему проверяли не поверхностно, а системно. #QA #тестирование #качество #разработка