Телеграм канал «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

⁣Retry-шторм как скрытая DDOS при cascading-отказах в async-оркестраторах

Ретри-логика кажется безобидной, пока не происходит каскадный отказ. В production я встречал ситуацию, где падение одного сервиса через саги превратилось в лавину ретраев, положившую всю инфраструктуру за 3 минуты. Ошибка в том, что разработчики и QA считают retry безопасным механизмом, не учитывая exponential growth нагрузки при одновременных вызовах.

Анатомия retry-шторма
Когда async-оркестратор (сага, workflow-движок) видит ошибку от downstream-сервиса, каждый экземпляр workflow запускает ретрай с экспоненциальной задержкой. При cascading-отказе, например падении БД, сотни оркестраторов одновременно выполняют шаги, каждый генерирует 3-5 ретраев. Итоговая нагрузка растет квадратично: 100 запросов в секунду превращаются в 10 тысяч ретраев за пару минут. Мониторинг показывает рост 5xx, но истинная причина — забитые очереди — не видна на графиках. Восстановление занимает часы вместо минут, как на реальном проекте после падения кластера БД.

Примитивный код-пример с проблемой
Допустим, в aiohttp воркфлоу вызывает сервис с ретраем:

async def call_service(session, url, retries=0):
try:
async with session.get(url) as resp:
resp.raise_for_status()
except ClientError:
if retries < MAX_RETRIES:
await asyncio.sleep(2 ** retries) # экспоненциальная задержка без jitter
return await call_service(session, url, retries + 1)
raise

Проблема: нет circuit breaker и rate limiter, jitter отсутствует. Экспоненциальная задержка без случайности даёт синхронные волны ретраев.

Практический совет: защита через три механизма
Добавьте circuit breaker, который отключает ретраи при ошибке сервиса. Используйте jitter для размазывания задержки:

import random

await asyncio.sleep((2 ** retries) + random.uniform(0, 0.5))

Также внедрите глобальный rate limiter на уровне оркестратора. После 2-3 ретраев сразу отправляйте запрос в dead-letter queue для ручного разбора.

Типичная ошибка: игнорирование cascading-отказов в тестах
Многие QA ограничиваются unit-тестами ретраев с изолированными вызовами. В реальном production retry-шторм возникает только при массовых отказах. Если у вас нет тестов, где симулируется падение БД с последующим восстановлением — вы не видите, как нагрузка расходится по очередям. Это скрытая DDOS, которая не выдаёт себя на стандартном мониторинге (CPU, memory, latency). Мой совет: заведите сценарий с cascading-отказом, используя инструменты вроде chaos engineering, и измеряйте количество ретраев в очередях. Источники: Martin Kleppmann, "Designing Data-Intensive Applications"; AWS Well-Architected Framework; GitHub Outage 2023.

Вывод: Retry-шторм — скрытая DDOS, требующая circuit breaker, jitter и rate limiting, иначе cascading-отказ в async-оркестраторах может привести к часам простоя.