Нефункциональное
11 статей
-
Fuzz-тестирование: как ломать вход мусором и находить то, что руками не поймать
Ручные кейсы проверяют то, что ты придумал, а баги живут там, где ты не придумал. Разбор от первого лица: что такое фаззинг и почему у него другой оракул (ловим факт падения, а не «правильный ответ»); виды — тупой, coverage-guided (AFL++/libFuzzer), property-based (Hypothesis/fast-check); где QA реально применяет (парсеры, загрузка файлов, API по OpenAPI, поля ввода, бизнес-логика); что фаззинг находит, а ручные кейсы нет; инструменты и как подступиться, чтобы это жило в CI.
-
Rate limiting — как тестировать лимиты, о которых вспоминают после инцидента
Пока никто не долбит API, кажется, что лимиты не нужны — их отсутствие незаметно ровно до первого инцидента. Разбор от первого лица: лимит как контракт двух сторон (сервер ограничивает — клиент переживает), граница N/N+1 и честный 429 с Retry-After, скоуп ключа и как лимитом по аккаунту устраивают DoS жертве, burst на стыке окон, обходы через X-Forwarded-For и соседние эндпоинты, зоны, где лимит обязан быть (OTP, reset, промокоды), и почему «лимиты выключены на стейдже» = непротестированный прод.
-
«У меня показывает старое» — как тестировать кэши, самый тихий источник багов
Баг «у юзера старые данные» не воспроизводится, закрывается как «само прошло» — и возвращается через неделю. Это не мистика, это кэш. Разбор от первого лица: карта из шести слоёв кэширования (браузер, CDN, gateway, приложение, БД, мобильный клиент), инвалидация как главный кейс, кэш и чужие данные, cache stampede после деплоя, правило «каждый кейс дважды — холодный и тёплый», и почему тестировать с выключенным кэшем = не тестировать прод.
-
Chaos Engineering для QA: как намеренно ломать систему, чтобы проверить отказоустойчивость
Отказоустойчивость, которую не проверяли намеренным сбоем, — это предположение, а не факт. Chaos Engineering для QA: steady-state hypothesis, blast radius и кнопка аборта, какие сбои вносят (kill инстанса, latency, отказ зависимости, исчерпание ресурсов, зональный отказ), инструменты (Chaos Monkey, Gremlin, Chaos Mesh, AWS FIS, Toxiproxy), Game Days, роль QA (graceful degradation, ретраи, circuit breakers, наблюдаемость) и чек-лист безопасного эксперимента.
-
Observability для QA: логи, метрики, трейсы — что проверять и как пользоваться
Observability глазами тестировщика: три столпа (логи/метрики/трейсы) простым языком, как тестировать саму наблюдаемость (trace id, метрики, секреты в логах), как QA использует её для локализации распределённых багов и тихих деградаций, SLI/SLO/error budget и чек-лист observability-ready фичи.
-
Нагрузочное тестирование: как спроектировать и не получить мусорные цифры
Как делать load-тесты правильно: виды (load/stress/soak/spike/breakpoint), перцентили вместо средней, открытая vs закрытая модель, реалистичные данные и профиль трафика, серверные метрики и сатурация, coordinated omission, инструменты k6/Gatling/Locust/JMeter. Чек-лист на 12 пунктов.
-
Performance тесты мобильной игры: 7 метрик, которые реально важно проверить
«Игра тормозит» — слишком абстрактно для тикета. Чтобы performance-проблема была воспроизводимой, измеряемой и трекабельной — нужны конкретные числа. Вот 7 метрик.
-
JWT-токены: что должен проверять QA
JWT — стандарт авторизации в современных приложениях. Базовый набор тестов и атак, которые должен знать каждый тестировщик.
-
OWASP Top 10 для тестировщика: что должен знать каждый QA
Security testing — не только pentest. Базовые уязвимости из OWASP Top 10 должен уметь проверять каждый QA. Не доверять разработке.
-
k6 vs JMeter: что выбрать для нагрузочного тестирования в 2026
JMeter — классика 20+ лет. k6 — современный претендент. Сравнение для команд которые выбирают сейчас.
-
JMeter: пошагово для первого нагрузочного теста
Нужно проверить выдержит ли API 1000 пользователей? JMeter — рабочий тул для этого. Гайд от нуля до первого результата.