Телеграм канал «QA-Логия»

6 ошибок в метриках дефектов, из-за которых QA теряет контроль над качеством

Когда дашборд зеленеет, число багов падает, а команда получает похвалу — это может быть ловушкой. Через пару недель прод ловит инцидент на ровном месте. Так бывает, если метрики дефектов становятся целью для отчёта и подменяют реальное управление качеством.

В статье разобрано шесть типовых ошибок. Первая — количество багов как личный KPI. Это заставляет QA скрывать дефекты или не заводить их вовсе, чтобы выглядеть лучше в глазах руководства. Вторая — доля переоткрытых задач. Эту метрику легко обойти красивой статистикой: если закрыть баг без реального воспроизведения, процент переоткрытых останется низким, хотя проблема никуда не делась. Третья — игнорирование сегментации дефектов. Например, когда все баги складываются в одну корзину, теряется понимание, какие из них критичны для прода, а какие — косметические. Четвёртая — фокус на проценте закрытых багов без учёта времени их жизни. Пятая — неиспользование плотности дефектов: метрика, показывающая количество багов на единицу кода, часто упускается, хотя именно она выявляет проблемные модули. Шестая — стремление к нулю открытых багов. Это иллюзия: некоторые дефекты невозможно закрыть, их нужно документировать и взвешивать риски.

Каждая из этих ошибок ведёт к тому, что реальное качество продукта ухудшается, а цифры на дашбордах остаются зелёными. Статья предлагает пересмотреть подход к метрикам: не гнаться за красивыми отчётами, а использовать метрики для честного анализа состояния продукта.

Читать далее

⁣Роль продукта в тестировании: как понять, что ты поймал настоящий баг или просто «пофиг» для бизнеса

Каждый, кто работает в тестировании, через это проходил. Находишь баг, аккуратно описываешь шаги, прикладываешь логи. А продакт смотрит и говорит: «пофиг, так и задумано». Или просто закрывает задачу. Бесит. Но если присмотреться — продукт это не про идеальный код, а про бизнес.

Первое, что стоит усвоить: баг и ошибка в коде — не одно и то же. Багом я называю то, что мешает пользователю сделать то, зачем он пришёл. Или мешает бизнесу заработать. Если кнопка «Купить» не работает — это баг, и его надо фиксить вчера. Если съехал отступ на пиксель — скорее всего, пофиг. Если только вы не тестируете интерфейс для дизайнеров с лупой.

Как отличить одно от другого? Настоящий баг ломает логику. Пользователь не может завершить сценарий, теряет деньги или время. А «пофиг» — это косметика, редкий кейс у пары человек из десяти тысяч, или то, что можно отложить без последствий.

Продакт обычно считает так: «Сколько мы потеряем, если не починим?» Вопрос, который стоит задавать себе: «Сколько пользователей от этого пострадает?» Если ответ «единицы» — готовься, что баг закроют. Даже если технически он выглядит критичным.

Типичная ошибка джуниоров — считать, что любой баг надо фиксить немедленно. Если дефект не влияет на конверсию или удержание — продакт вправе сказать «пофиг». И это не про то, что ты плохо проверил. Это про разницу между ошибкой в коде и ошибкой в продукте.

Что с этим делать? Пара вещей, которые работают у меня.

* Перед тем как заводить баг, спрашиваю: «Почему это важно для пользователя?» Если ответ абстрактный — скорее всего, приоритет низкий.
* Потом смотрю в аналитику. Если баг ловит 5 из 10 000 — не трачу время на многостраничное описание.
* И аргументирую бизнес-цифрами: «Из-за этого 20% пользователей кликают мимо, теряем столько-то конверсий».

И не обесценивай себя, когда продакт закрывает баг. Твоя задача не найти всё, а научиться отфильтровывать через призму бизнеса. Тогда из просто «багоискателя» вырастаешь в инженера, который на продукт влияет.

А у тебя было, что продакт закрывал баг, а он потом «выстрелил»? Расскажи в комментариях.

⁣AI-инструменты, которые искажают реальные баги: когда генерация тестовых данных создаёт ложную уверенность

Я часто вижу, как QA-инженеры, особенно junior, попадаются в ловушку "магии AI". Берут инструмент, генерирующий тестовые данные по описанию требований, и расслабляются. Кажется, что все под контролем. А потом продакшен падает из-за граничного случая, который AI не заметил.

AI-генерация данных - штука полезная, но и зона риска. Она искажает картину реальных багов.

Во-первых, AI учится на "идеальных" данных. Он знает, как выглядит типичная строка, дата, email. Но баги живут в аномалиях. AI не сгенерирует строку с нестандартным Unicode-символом или дату 29 февраля 2023 года, если проект этого не требует. Он создает комфортную "прическу" для данных, а не реальную грязь, на которой падает система.

Во-вторых, инструменты игнорируют бизнес-контекст. AI может сгенерировать 1000 корректных заказов на складе, но не поймет, что 500 из них - просрочка, а 300 - без цены. Вы тестируете функционал, думая, что данные корректны, а система работает как идеальная.

В-третьих, ложная уверенность. Автотесты на AI-данных зеленые, но вручную их никто не проверяет. Баг "товар не отображается при нулевом остатке" маскируется AI-генерацией, которая не создала таких записей.

Решения:
* Не доверяйте AI без ручной проверки. Каждый сгенерированный набор анализируйте на граничные условия.
* Используйте AI как черновик, а не финал. Проверяйте, где могут быть дыры.
* Тестируйте на "грязных" данных: аномальные символы, кривые даты, пустые поля, переполнения.
* Смешивайте AI (80% базиса) и ручную генерацию (20% "бомб" из опыта продакшена).

AI - молоток. Если им забивать шурупы, стена кривая. Генерация без контроля создает иллюзию покрытия, а не защиту. Будьте умнее: проверяйте, где AI слеп, и закрывайте дыры руками.

Анатомия парного доклада: как мы собирали «PROvoke» на Analyst Days. Часть 1 — подготовка

На прошлых Analyst Days авторы с Татьяной Маркиной зашли на территорию, где обычно стараются не светиться — тему манипуляций и провокаций в системной аналитике и IT. Они решили сделать парный доклад, чтобы показать не только результаты, но и сам процесс взаимодействия в аналитике на сцене.

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

Ключевым решением стал выбор сценария: решили строить выступление вокруг реального кейса, но с долей театрализации. Каждый из докладчиков взял на себя определенную роль, чтобы проиллюстрировать типичные конфликты в команде. Это позволило погрузить зрителей в атмосферу рабочей дискуссии, не скатываясь в сухую теорию. В итоге получился формат, который авторы назвали «PROvoke», балансирующий между обучением и развлечением.

Читать на Хабре

⁣Resource-leak в async context propagation: детекция orphaned tracing spans при неполной очистке OpenTelemetry baggage

Baggage в OpenTelemetry — тихий убийца памяти в асинхронных средах. В высоконагруженных продакшн-системах неполная очистка контекста после завершения span приводит к орфан-спанам и утечкам, которые часто маскируются под необъяснимый OOM. QA и разработчики ошибочно фокусируются на самих трейсах, игнорируя корень — незакрытый baggage.

Как возникает утечка: асинхронный контекст без очистки

В Go или Kotlin Coroutines после завершения span baggage остаётся в контексте. Пример на Go:

func process(ctx context.Context) {
ctx, span := tracer.Start(ctx, "operation")
defer span.End()
baggage.Set(ctx, baggage.String("key", "value"))
// goroutine продолжает работать с контекстом
}

Span закрылся, но baggage живёт. Этот контекст кочует между горутинами, цепляя orphaned spans — трейсы без родителя. Они не закрываются, память растёт, trace tree превращается в кашу.

Четыре метода детекции

* Метрики: смотри на otel_span_count с status_code = Unset. Высокий счётчик — явный признак утечки.
* Логи: middleware после завершения scope проверяет, пустой ли baggage. Если нет — предупреждение в лог.
* Анализ trace tree: если span при ожидании не видит родителя с помощью Span.current(), он почти гарантированно orphaned.
* Алерты по baggage: отслеживай рост количества spans с одинаковыми ключами — триггер для баг-трекинга.

Практический совет: обязательная очистка

В Go: defer baggage.Clear(ctx) после завершения операции. В Kotlin Coroutines используй OpenTelemetryContextElement. В Java с CompletableFuture — явно чисти контекст перед каждым .thenApply. Это предотвращает утечки независимо от инструмента.

Типичная ошибка: игнорирование асинхронных блоков

Опасность не в падении одного сервиса. В high-load системе тысяча болтающихся контекстов через пару часов даёт OOM, а трейсы в дампе ничего не объясняют: spans есть, цепочек нет. Проверять надо все асинхронные блоки: goroutine, async/await, CompletableFuture, корутины. Если есть JVM-мониторинг — смотри jvm.memory.used в разрезе контекстов.

Для тестов полезна эмуляция контекста: запускаешь асинхронную операцию, ждёшь completion, проверяешь, что baggage чистый. Если нет — тест красный.

Вывод: В production-oriented QA первым делом проверяй очистку baggage в асинхронных цепочках — это дешевле, чем разбирать OOM с кашей из orphaned spans в дампе.

⁣Диагностика дрейфа библиотек шифрования в gRPC middlewares через слепую смену версий в production

Регресс на стейджинге — не всегда следствие плохого кода. Часто проблема скрыта в библиотеке шифрования, которая тихо поменяла версию: OpenSSL на BoringSSL или GnuTLS, а gRPC middleware перестал согласовывать cipher suites. Разработчики и QA это редко замечают, пока production не падает на handshake.

Почему это ломает gRPC
Шифрование в gRPC работает через middlewares — перехватчики всех запросов. Если подменить BoringSSL на GnuTLS, может измениться порядок cipher suites, отвалиться OCSP stapling или сломаться handshake для клиента с устаревшим proto. Пример из практики: после замены OpenSSL на BoringSSL на прокси Envoy упал весь трафик, так как новый порядок suites не поддерживали старые клиенты. Ни один CI регресс это не поймал — тесты запускались на том же стейджинге, без изоляции версий.

Пассивная диагностика
Добавьте в gRPC клиент interceptors для логирования версии библиотеки. Например, через переменную окружения TLS_LIB_VERSION (если не задана — unknown). Это даёт картину при разборе ошибок. Но пассивное логирование не ловит дрейф до сбоя.

Активное тестирование с подменой
Запустите канареечный тест на малом проценте трафика: временно подмените OpenSSL на BoringSSL через подготовленный контейнер. Метрики для мониторинга:
* время handshake (допуск — не более 5% отклонения)
* количество ошибок UNAVAILABLE
* разница в cipher suites на прокси (HAProxy или Envoy)

В production мне так вскрылась несовместимость по OCSP, которую регресс не поймал: старый сертификат не проходил проверку на новом BoringSSL. Обязательно используйте feature flag для отката и логируйте sha256 бинарника библиотеки, чтобы точно знать, что подменили.

Типичная ошибка
Не верьте, что если регресс прошёл на стейджинге, то всё чисто. Без изоляции версий вы не заметите дрейф библиотек. Слепая смена — не проблема, если есть active monitoring. Но без неё вы просто молитесь, что handshake не сломается.

Вывод:
Активное тестирование с подменой библиотек и мониторинг метрик handshake — единственный способ поймать несовместимости шифрования, которые регресс пропускает до падения production.

«Освоение модульного тестирования с использованием Pytest» курс на Stepik

Сегодня умение писать тесты ценится почти так же, как и умение писать сам код. Если pytest, fixtures, CI/CD и coverage всё ещё вызывают вопросы самое время это исправить

Программа курса:

• Pytest: от базовых тестов до CI/CD
• fixtures, mocking, parametrization
• Flask/API testing
• Selenium и UI тестирование
• Docker + Docker Compose
• GitHub Actions
• coverage и отчёты
• debugging и refactoring тестов

Курс построен вокруг практики: много примеров, готовых кейсов и разборов рабочих сценариев

48 часов действует скидка 25%

↗️ Пройти курс на Stepik