Ответ
Bug Leakage (Утечка дефектов) — это метрика и ситуация в тестировании, когда дефекты, существовавшие в системе на момент определённой фазы тестирования (например, системного тестирования), не были в ней обнаружены, но были выявлены позже — на следующей фазе (приёмочное тестирование) или, что хуже, в production-среде конечными пользователями.
Чем отличается от Bug Release?
- Bug Leakage: дефекты пропущены тестировщиками на конкретном этапе.
- Bug Release: дефекты известны, но сознательно не исправлены перед релизом (например, из-за низкого приоритета).
Типичные причины утечки дефектов:
- Недостаточное тестовое покрытие: отсутствуют тест-кейсы для сложных, редких или интеграционных сценариев.
- Ошибки в тест-дизайне: тесты не отражают реальное использование продукта.
- Ограничения тестовой среды: различия между тестовой и production-средой (данные, конфигурация, нагрузка).
- Человеческий фактор: ошибки тестировщиков, усталость, невнимательность.
- Сжатые сроки: вынужденное сокращение объёма регрессионного тестирования.
Пример: В мобильном банке функция «быстрый платёж по шаблону» корректно работала в тестовой среде с подготовленными данными. Однако после релиза у пользователей со сложными шаблонами (много получателей, разные валюты) операция завершалась ошибкой. Дефект «утек», так как тестирование не покрывало все возможные комбинации шаблонов.
Методы предотвращения:
- Риск-ориентированное тестирование: фокус на наиболее критичных и часто используемых функциях.
- Использование production-like данных и среды для тестирования.
- Автоматизация регрессионных тестов для ключевых сценариев.
- Проведение exploratory-тестирования для выявления неочевидных сценариев.
- Внедрение практик shift-left: привлечение тестировщиков к обсуждению требований на ранних этапах.
Ответ 18+ 🔞
Да ты посмотри, какая интересная штука вылезла! Сидит себе команда, пыхтит, тестирует, все по плану, все кейсы прошли — красота! Выкатывают релиз, а там, блядь, пользователи как начнут орать: «У меня ничего не работает, всё сломалось, вы идиоты!». А это, сука, не баг-релиз, где сознательно оставили какую-нибудь мелочь. Это — Bug Leakage, утечка дефектов, ёпта! То есть жучок сидел, притаился, а наши тестеры его просрали, прости господи, на своём этапе.
И в чём разница-то, спросишь?
- Bug Leakage (Утечка): Дефект был, а мы его, слепые кроты, проморгали. Он от нас утёк, как вода сквозь пальцы.
- Bug Release (Выпуск): Дефект знали, посмотрели на него, плюнули и сказали: «Да похуй, пусть живёт, не критично». Сознательное решение, а не прокол.
А почему это, сука, постоянно происходит? Ну вот же, классика жанра:
- Покрытие тестами — хуйня. Написали кейсы на сферического коня в вакууме, а как пользователь начинает извращаться со всеми настройками — пиздец. Сложные сценарии? Интеграция? Да кто ж их тестировать-то будет, сроки горят!
- Тест-дизайн от балды. Сидели, думали, как будет использоваться продукт... да хуй там плавал! В реальности пользователи — это мартышлюшки с гранатой, они всегда найдут способ сломать то, что, по нашей задумке, ломаться не должно.
- Тестовая среда — пиздец. У нас там один сервер, два веника и база данных на три записи. А в продакшене — овердохуища нагрузки, реальные данные и конфигурация, про которую мы и не слышали. Ну и как тут баг найти?
- Человеческий фактор, блядь. Устал тестировщик, замылился глаз, кофе не помог. Пропускает шаг, не видит очевидного. Волнение ебать, терпения ноль ебать — и вот он, пропущенный дефект.
- Сроки, сука, сроки! «Ребята, надо вчера! Регресс? Да пробегитесь по основному, остальное — авось пронесёт!». Не проносит, блядь. Никогда не проносит.
Пример, чтобы совсем понятно было: Делали мобильный банк. Функция «быстрый платёж по шаблону». В тестах всё летало: один шаблон, один получатель. Выкатили. А тут бабка-пенсионерка, у которой шаблонов на пять страниц, с разными валютами и условиями, тыкает в кнопку — и получает ошибку такую, что хоть святых выноси. Дефект-то утёк! Потому что тестировали на простых случаях, а до сложных комбинаций руки не дошли, или, простите, мозги.
Как с этим бороться, чтобы не выглядеть идиотами?
- Тестируй, где больно. Риск-ориентированный подход, ёбта! Сначала лови баги в самом важном и хрупком, а потом уже во всём остальном.
- Тестовая среда должна быть как продакшен. Ну или максимально близко. И данные бери настоящие (обезличенные, конечно), а не те, что на коленке слепил.
- Автоматизируй, блядь, регресс! Чтобы каждый раз не полагаться на уставшие глаза и кривые руки. Ключевые сценарии должны прогоняться железной тупой машиной.
- Exploratory-тестирование — наш бро. Сесть и просто потыкать продукт, как это сделал бы ебучий пользователь, который вчера родился. Самые жирные баги часто так находятся.
- Shift-left, ёпта! Не жди, пока код напишут. Влезай в обсуждение требований сразу, задавай неудобные вопросы. Лучше баг в голове аналитика поймать, чем в проде у пользователя.