qa
16 статей
-
Rate limiting — как тестировать лимиты, о которых вспоминают после инцидента
Пока никто не долбит API, кажется, что лимиты не нужны — их отсутствие незаметно ровно до первого инцидента. Разбор от первого лица: лимит как контракт двух сторон (сервер ограничивает — клиент переживает), граница N/N+1 и честный 429 с Retry-After, скоуп ключа и как лимитом по аккаунту устраивают DoS жертве, burst на стыке окон, обходы через X-Forwarded-For и соседние эндпоинты, зоны, где лимит обязан быть (OTP, reset, промокоды), и почему «лимиты выключены на стейдже» = непротестированный прод.
-
Первые 30 дней QA на новом проекте — как въехать и не наделать глупостей
Первый день: продукт незнакомый, стенды непонятные, а тебя уже просят «глянуть одним глазом фичу». Разбор от первого лица: свежий взгляд как ресурс с истекающим сроком, неделя в роли юзера, карта рисков из трёх вопросов команде («что чаще ломается? какой был последний инцидент? куда боитесь лезть?»), образцовые первые баг-репорты, почему критиковать процессы на второй неделе — худший ход, первые маленькие улучшения к концу месяца и чек-лист 30 дней.
-
Автотесты, которые не в CI, — это хобби: как встроить тесты в пайплайн и не утонуть
400 автотестов, которые гоняются «иногда, локально» — это не автоматизация. Разбор от первого лица: слои прогонов (PR-гейт с бюджетом в минуты / после merge / ночью), шардирование и почему параллель валит зависимые тесты, retry-политика без маскировки флаки (passed-on-retry = жёлтый, не зелёный), карантин с двумя выходами, правило красного main, артефакты падений (trace вместо повторного дебага) и метрики здоровья suite.
-
Чек-лист тестирования регистрации и логина — и автотест на Playwright под каждый пункт
Логин — первый экран, который видит юзер, и любимое место продакшн-инцидентов. Формат «пункт чек-листа → как его автоматизировать»: user enumeration через одинаковые сообщения, password reset с одноразовым токеном, logout и кнопка «назад», cookies HttpOnly/Secure через context.cookies(), сессия в двух вкладках, мок 429 для блокировки, паттерн storageState чтобы не логиниться в каждом тесте — и что в auth принципиально не стоит тащить в e2e.
-
Тестирование обновлений — баги, которые видят только юзеры со старой версией
Релиз идеально протестирован — на чистой установке. А почти все юзеры получат его обновлением поверх старой версии со старыми данными. Разбор от первого лица: почему апдейт = новый код читает старые данные, матрица версий N-5 → N и цепочки миграций, обновление посреди сессии, force update и его обходы, staged rollout и сервер на две версии, downgrade как краш-луп, первый запуск после апдейта ≠ FTUE — и почему в шкафу должен лежать архив старых билдов.
-
«У меня показывает старое» — как тестировать кэши, самый тихий источник багов
Баг «у юзера старые данные» не воспроизводится, закрывается как «само прошло» — и возвращается через неделю. Это не мистика, это кэш. Разбор от первого лица: карта из шести слоёв кэширования (браузер, CDN, gateway, приложение, БД, мобильный клиент), инвалидация как главный кейс, кэш и чужие данные, cache stampede после деплоя, правило «каждый кейс дважды — холодный и тёплый», и почему тестировать с выключенным кэшем = не тестировать прод.
-
«Сколько займёт тестирование?» — как давать оценку и не закапывать себя
Цифру «дня два» ты называешь за три секунды, а живёт она потом недели — и используется против тебя. Разбор от первого лица: почему оценка тестирования — особый жанр (ты оцениваешь качество чужой работы, которой ещё нет), эстимейт как прогноз с допущениями, декомпозиция вместо одной цифры, три точки вместо одной, именованный буфер вместо «×2 на всякий случай» и что говорить, когда время режут.
-
Что автоматизировать, а что оставить руками — и почему «автоматизируем всё» убивает suite
«Автоматизируем всё» через полгода превращается в красный suite, которому никто не верит. Разбор от первого лица: тест, который чинили полгода, а надо было удалить; почему автотест стоит не «написать», а «содержать годами»; что стоит автоматизировать (стабильное, частое, дорогое руками, детерминированное) и что оставить человеку; пирамида как калькулятор решений; почему флаки-тест хуже отсутствующего и чек-лист «автоматизировать или нет».
-
Состояния экрана: empty, loading, error и то, что забывают, пока не прилетит баг
Экраны проектируют для happy path, а пользователь первым видит загрузку, пустоту или ошибку. Разбор от первого лица: пустой экран, который выглядит как зависшая загрузка; почему «ещё ничего нет» и «ничего не найдено» — разные пустоты; почему ошибку нельзя путать с пустотой; offline, частичная загрузка, устаревшие данные, ошибка на догрузке; доступность пустых и ошибочных состояний и компактный чек-лист.
-
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, наблюдаемость) и чек-лист безопасного эксперимента.
-
Как QA и разработчику не воевать: репорт багов и обратная связь без конфликта
Конфликт QA и разработчика почти всегда не про баг, а про подачу. Как репортить баги и давать обратную связь без трения: баг про продукт, а не про человека; структура репорта, снимающая защиту; язык фидбека (SBI и формула Lara Hogan); severity без драмы; что делать с «works as designed»; shift-left; когда эскалировать; культура blameless и чек-лист на 10 пунктов.
-
Чек-лист тестирования поиска и фильтров — и как автоматизировать каждый пункт на Playwright
Поиск и фильтры есть почти везде, и баги в них одни и те же. Чек-лист того, что проверять (граничные запросы, debounce, гонка запросов, пустое состояние, XSS, фильтры в URL, устойчивость к ошибкам бэкенда, локализация) — и для каждого пункта реальный автотест на Playwright через перехват сети page.route. Плюс что НЕ стоит автоматизировать в e2e.
-
Observability для QA: логи, метрики, трейсы — что проверять и как пользоваться
Observability глазами тестировщика: три столпа (логи/метрики/трейсы) простым языком, как тестировать саму наблюдаемость (trace id, метрики, секреты в логах), как QA использует её для локализации распределённых багов и тихих деградаций, SLI/SLO/error budget и чек-лист observability-ready фичи.
-
Выгорание в QA: ранние признаки, причины и как вытащить себя и команду
Выгорание у тестировщиков: чем оно отличается от усталости (3 измерения по ВОЗ), почему QA в зоне риска, ранние признаки, три уровня причин (личные/командные/процессные), что реально помогает, что делать тимлиду и мини-чек-лист самопроверки.
-
Собеседование на QA в 2026: как готовиться и что реально спрашивают
Карта подготовки к собеседованию на QA: теория и техники тест-дизайна, severity vs priority, фреймворк ответа на «протестируй X», баг-репорт, API/SQL-минимум, автоматизация, поведенческие по STAR, красные флаги компании. Чек-лист на 10 пунктов.
-
Knight Capital: как $440 млн испарились за 45 минут из-за одного деплоя
Разбор катастрофы 1 августа 2012 года глазами QA: переиспользованный feature-флаг, незамеченный 8-й сервер, мёртвый код Power Peg и 97 проигнорированных алертов. 7 уроков и чек-лист релиз-процесса на 10 пунктов.