qa
53 статей
-
Ребаланс живой игры: как я дважды сломал старых игроков и почему тест был зелёным
Я переделал баланс своей idle-игры, и игрок с прокачанной башней умер на первой волне. Я выпустил фикс с тестом — и тот же игрок написал: «у меня миллионы HP, но я не могу убить ни одного врага». Тест был зелёным, потому что проверял номер волны, а не убийства. Разбор от первого лица: почему ребаланс — это миграция данных, какие сейвы брать в тест и как проверять исход, а не прокси.
-
Фантомные пользователи: откуда в аналитике мобильного приложения берутся «боты» и как их отличить от фрода
В аналитике внезапно появляется пачка новых пользователей с одной и той же старой моделью телефона: открыли приложение, потыкали минуту и ушли. Первая мысль — фрод и слитый рекламный бюджет. Часто это роботы самого Google из pre-launch report. Разбираем, как отличить тестовые устройства от ботов, как проверить источник за пять минут и как отфильтровать такой трафик, чтобы он не портил воронку и ретеншн.
-
Утечки памяти: как поймать баг, который появляется только через час
Приложение отлично работает пять минут и падает через час. Классическая утечка памяти, которую не ловит ни один короткий тест-кейс. Разбираем, как утечка выглядит со стороны QA, какие сценарии её проявляют, как мерить память на Android, iOS, в Unity и в браузере, и что приложить к баг-репорту, чтобы разработчик нашёл причину за час, а не за неделю. С чек-листом.
-
Право сказать «нет» релизу: когда QA блокирует выпуск и как это делать без войны
Пятница, вечер, релиз через час, а у тебя на руках баг. Блокировать или промолчать? Разбираем, почему QA не шлагбаум, но и не наблюдатель, когда «нет» оправдано, как его сформулировать, какие есть варианты между «да» и «нет», и что делать, если релиз выпускают вопреки твоей рекомендации. С чек-листом.
-
Remote Config: как тестировать то, что меняется без релиза
Хотфикс через Remote Config не применился, потому что старый конфиг перекрыл новый, а «починили» мы на сборке, которой у игроков нет. Разбор от первого лица: версии конфигов, когда изменения реально доходят до игрока, совместимость со старыми клиентами и чек-лист для QA.
-
Баланс игры ломается не багом, а цифрами: как я ловил эксплойты симулятором
Тестер прошёл мою idle-игру до 199 волны за вечер, хотя всё «работало». Разбор от первого лица: почему баланс не проверить руками, как написать симулятор игрока, стресс-тест «максимально прокачанного» билда и какие четыре дыры он нашёл. С чек-листом для QA.
-
Баг ушёл в прод: как QA пройти постмортем и не стать виноватым
Пропущенный баг в проде — момент, когда тестировщика тянет либо оправдываться, либо съесть себя. Оба пути ведут не туда. Разбираем, почему «кто виноват» — неправильный вопрос, что делать в первые часы, как устроен blameless-постмортем, какие action items реально что-то меняют, и как жить в команде, где виноватого всё-таки ищут. С чек-листом.
-
Повторный запрос — не повторная операция: как QA тестировать retries
Практический план проверки повторных запросов: идемпотентность, таймауты, дубли, порядок ответов и восстановление после обрыва сети.
-
Логи сливают токены: как QA проверить диагностику на утечки
Практический план проверки логов, аналитики и crash-reporting: синтетические маркеры, ошибки, вложенные поля, смена аккаунта и контроль доставки событий.
-
Выгорание в QA: почему тестировщики выгорают иначе — и что с этим делать
Выгорание у QA имеет свои триггеры: ты вечно приносишь плохие новости, ты бутылочное горлышко перед релизом, а «поймал баг» — работа невидимая, «пропустил» — виноват. Разбираем QA-специфичные причины, ранние признаки, что реально помогает (и что нет), чек-лист самопроверки на 8 пунктов и что просить у тимлида на 1-1.
-
Визуальное регрессионное тестирование: инструменты и подходы в 2026
Функциональные тесты зелёные, а вёрстка поехала: кнопка съехала, текст обрезан, тема сломалась. Это ловит визуальное регрессионное тестирование. Разбираем, что это, почему «голые» скриншоты флакают, и инструменты 2026: Playwright toHaveScreenshot, Lost Pixel, Percy, Applitools Eyes, Chromatic — матрица и кому что.
-
Page Object Model: архитектура UI-автотестов, чтобы не утонуть в поддержке
Локаторы и шаги прямо в тестах — бомба замедленного действия: поменяли кнопку, чинишь в 50 местах. Page Object Model: класс на страницу инкапсулирует локаторы и действия, тесты вызывают методы. Что внутри Page Object, чего там быть не должно, Component Objects, fluent/loadable, анти-паттерны и когда POM избыточен.
-
Тестирование прерываний и жизненного цикла мобильного приложения
Мобилка живёт не в вакууме — ОС в любой момент вмешивается, и именно там баги. Прерывания (звонок, пуш, шторка, split-screen), жизненный цикл и убийство процесса в фоне, поворот экрана, обрывы сети, low-memory kill и энергосбережение, отзыв разрешений. Чек-лист и как это воспроизводить.
-
Bruno vs Postman vs Insomnia: какой API-клиент выбрать в 2026
Postman ушёл в облако и обязательный логин — команды массово мигрируют. Сравниваем три API-клиента в 2026: Postman (мощный, но cloud-first и vendor lock-in), Bruno (open-source, offline, коллекции как .bru-файлы в git) и Insomnia. Матрица, что важно QA, и как переехать с Postman.
-
Как QA договариваться с разработчиком: «это не баг», приоритеты и тон без войны
Половина работы QA — не найти баг, а добиться, чтобы его починили. Как отвечать на «это не баг, это фича», чем severity отличается от priority, как писать баг-репорт без споров, держать тон «сломано поведение, а не ты сломал», что делать при «не воспроизводится» и когда эскалировать.
-
Ожидания в UI-автотестах: почему тесты флакают и как ждать правильно
№1 причина flaky-тестов — неправильные ожидания. Почему sleep() всегда проигрывает, чем коварен implicit wait, как ждать условие через explicit wait, что меняет auto-wait в Playwright/Cypress, и как переписать флакающий тест с таймера на состояние.
-
Чек-лист тестирования дат, времени и таймзон
Даты — источник багов, которые всплывают в проде через полгода. Практический чек-лист: хранение в UTC, таймзоны, переход на летнее время (DST), форматы дат, границы (полночь, конец месяца, 29 февраля), расчёты через DST, относительное время и как всё это воспроизводить.
-
Playwright vs Cypress vs Selenium в 2026: что выбрать для E2E
Сравнение трёх главных E2E-фреймворков в 2026: Playwright (мультибраузерность, авто-ожидания, Trace Viewer, дефолт для новых проектов), Cypress (лучший DX и time-travel-дебаг) и Selenium (стандарт W3C, максимум языков и Grid). Матрица различий, кому что подходит и как не ошибиться с выбором.
-
Ariane 5, рейс 501: как одно переполнение взорвало ракету за 40 секунд
4 июня 1996 первая Ariane 5 самоликвидировалась через 37 секунд после старта. Причина — переполнение при конвертации 64-бит float в 16-бит int в переиспользованном коде Ariane 4. Разбор от первого лица: что произошло, почему дублирование не спасло, и шесть уроков для QA — про реюз кода, границы, мёртвый функционал, обработку ошибок и тест в реальной конфигурации.
-
Как доказать ценность QA: метрики и импакт, которые видит менеджмент
QA часто считают «тормозом» и cost-center, а «нашёл N багов» — плохая метрика. Разбор от первого лица: что НЕ мерить (число багов, тест-кейсов, часы), что показывать вместо (escaped defects, предотвращённое, риск-покрытие, скорость с качеством), стоимость бага по этапам, как доносить на языке бизнеса. С чек-листом, как сделать импакт QA видимым — и превратить его в аргумент на повышение.
-
Автоматизация API-тестов: с чего начать и что покрывать в 2026
API-тесты — фундамент пирамиды: быстрее и стабильнее UI, ловят баги логики раньше и дешевле. Разбор от первого лица: что проверять кроме 200 (схема, error-paths, авторизация, границы, идемпотентность), setup/teardown данных и изоляция, валидация контракта против OpenAPI/JSON Schema, инструменты 2026 (Playwright request, pytest+httpx, RestAssured, Hurl, Schemathesis). С чек-листом хорошего API-теста.
-
Чек-лист тестирования денежных сумм и чисел: 35 пунктов, где всё ломается
0.1 + 0.2 ≠ 0.3 — и это только начало. Деньги и числа — минное поле: float-погрешность, округление, локали, валюты, граничные значения. Разбор от первого лица: почему деньги не хранят во float, округление и split суммы, форматирование по локали, число знаков у валют, ввод пользователя, бизнес-логика скидок и налогов. С плоским чек-листом.
-
Как тестировать экономику мобильной игры и ловить читеров
Экономика игры — главная мишень: любой чит бьёт прямо по деньгам. Разбор от первого лица: почему клиенту нельзя верить (сервер-авторитет), дюп-баги и идемпотентность покупок, перевод часов устройства, редактирование сейва, отрицательный баланс и переполнение, фейковый IAP-чек, тулы читеров. С чек-листом атак, которые должен прогнать QA.
-
Отчёты автотестов 2026: Allure vs ReportPortal vs Currents vs нативный Playwright
«Зелёный/красный в консоли» — это не отчёт. Команде и менеджеру нужны история прогонов, тренды, детект флейков и шаринг. Разбор от первого лица: нативный Playwright HTML-report и Trace Viewer, Allure, ReportPortal, Currents/Cypress Cloud — что каждый даёт, чего не умеет, кому что подойдёт. С матрицей выбора и чек-листом хорошего отчёта.
-
Broken Access Control: как QA тестировать права доступа (топ-1 риск OWASP)
Битый контроль доступа — №1 в OWASP Top 10, и львиную долю таких дыр QA может поймать без пентестера. Разбор от первого лица: IDOR, горизонтальная и вертикальная эскалация привилегий, forced browsing, проверка на бэке (а не в UI), матрица ролей, подмена токенов. С чек-листом и типовыми местами, где это ломается.
-
Как сообщать плохие новости: баг перед релизом, сорванный срок, «качество просело»
QA — вечный носитель плохих новостей, и от того, КАК ты их доносишь, зависит, услышат тебя или запомнят как того, кто вечно ноет и «запрещает релиз». Разбор от первого лица: формула «факт → влияние → варианты → рекомендация», данные вместо эмоций, эскалация без драмы, роль «показываю риск, а не блокирую», разговор на языке разработчика / менеджера / стейкхолдера. С чек-листом и фразами-шаблонами.
-
Локаторы, которые переживут редизайн: стратегия селекторов для UI-автотестов
Чаще всего UI-автотесты падают не от багов, а от хрупких локаторов. Разбор от первого лица: приоритет селекторов (роль/лейбл → data-testid → текст → CSS → XPath в самом конце), почему XPath по позиции и автогенеренные классы — бомба замедленного действия, соглашение о data-testid с разработкой, ловушки динамического контента и i18n, кросс-тул (Playwright, Selenium, Cypress, Appium). С чек-листом хорошего локатора и списком антипаттернов.
-
Чек-лист тестирования транзакционных писем: 40 пунктов, о которых забывают
«Это же просто письмо» — и вот сброс пароля улетает в спам, в приветствии красуется «Здравствуйте, {{name}}», а ссылка протухла раньше, чем дошла. Разбор от первого лица: триггер и содержимое, доставляемость (SPF/DKIM/DMARC, спам), ссылки и токены, рендеринг в почтовых клиентах (тёмная тема, картинки выключены, Gmail/Outlook), тайминг/дубли/ретраи, локализация и unsubscribe. С плоским чек-листом.
-
Тестирование прерываний в мобильной игре: звонок, свёрнутое приложение и потерянная сессия
Игрок на решающем ходу — и тут звонок. Вернулся, а прогресс потерян, звук молчит, награда за rewarded-рекламу не пришла. Разбор от первого лица: каталог прерываний (звонок, пуш, сворачивание, блокировка, реклама, наушники, split-screen), что реально ломается при возврате, различия iOS и Android, как воспроизводить каждый кейс и чек-лист.
-
Тестирование восстановления из бэкапа: бэкап, который никто не восстанавливал
Бэкапы есть у всех — а восстановление не проверял почти никто. Разбор от первого лица: почему «бэкап прошёл успешно» ничего не гарантирует; что такое RTO и RPO и зачем их мерить; что реально ломается при восстановлении (битый архив, не тот момент, разъехавшаяся схема, чужое окружение, секреты); как проводить restore drill; и почему мониторить надо восстановление, а не факт бэкапа. С разбором инцидента GitLab 2017.
-
Тестирование фича-флагов и A/B-экспериментов: как не отправить в прод кашу из вариантов
Флаг — это не «вкл/выкл», а живая ветка кода в проде, которую надо тестировать в обоих состояниях. Разбор от первого лица: почему один флаг превращается в матрицу состояний; где живут злые баги таргетинга и sticky-бакетинга; как тестировать A/B-эксперимент как механику, а не гипотезу; kill switch, флаги-зомби и чек-лист перед релизом.
-
Тест на реальных девайсах: как собрать матрицу устройств и почему твой телефон врёт
Всё летало на моём Pixel, а в отзывах — «вылетает на старте». Реальные баги живут не на твоём девайсе. Разбор от первого лица: почему один-два телефона врут; как собрать матрицу по осям риска (ОС, класс железа, вендор/оболочка, экран, локаль) из своей аналитики; реальные девайсы vs эмуляторы vs облачные фермы; что тестировать именно на разном железе (OOM, термалка, вендор-киллинг, safe-area, апдейт поверх).
-
Fuzz-тестирование: как ломать вход мусором и находить то, что руками не поймать
Ручные кейсы проверяют то, что ты придумал, а баги живут там, где ты не придумал. Разбор от первого лица: что такое фаззинг и почему у него другой оракул (ловим факт падения, а не «правильный ответ»); виды — тупой, coverage-guided (AFL++/libFuzzer), property-based (Hypothesis/fast-check); где QA реально применяет (парсеры, загрузка файлов, API по OpenAPI, поля ввода, бизнес-логика); что фаззинг находит, а ручные кейсы нет; инструменты и как подступиться, чтобы это жило в CI.
-
Manual → automation: как перейти и не сломаться
«Выучи Python и Selenium» — самый частый и самый бесполезный совет. Переход в автоматизацию ломается не на синтаксисе. Разбор от первого лица: три ямы (автоматизируют всё подряд, думают что автоматизация — это «писать тесты», бросают ручное мышление), рабочий маршрут (язык по минимуму, старт с API-тестов, потом UI с архитектурой, Git/CLI/CI), почему manual-прошлое — преимущество (знаешь ЧТО автоматизировать, ты оракул, репро-шаги, исследование), и антипаттерны перехода.
-
Архитектура UI-автотестов: Page Object и что идёт после него
Хороший автотест-сьют меряется не количеством тестов, а стоимостью изменения. Разбор от первого лица: что такое Page Object на самом деле (прячет КАК за ЧТО), почему ассерты внутри объекта — антипаттерн, слои выше Page Object (компоненты, setup через API, тест-данные), где обычно переусложняют, и правило трёх против ранних абстракций. Плюс критерий здорового теста: он читается как сценарий пользователя, без селекторов в теле.
-
Чек-лист тестирования оплаты и чекаута — кейсы, на которых ломаются деньги
Чекаут — место, где сходятся деньги и доверие, а тестируют его чаще всего на тестовой карте 4242 и happy path. Разбор от первого лица: деньги в минорных единицах, а не во float; двойное списание и идемпотентность; отказы банка как норма, а не 500; 3-D Secure и брошенный челлендж; вебхук как источник истины, а не редирект; пересчёт сумм и промокодов на сервере; PCI и токенизация; обрывы сети на каждом шаге. Плюс плоский чек-лист на 16 пунктов.
-
LiveOps-ивенты — релизы без App Review, которые тестируют слабее всего
Игра живёт ивентами: батл-пассы, турниры и акции выкатываются серверным конфигом без релиза и без ревью стора — прямо на прод, поверх любой версии клиента. Разбор от первого лица: границы окна и таймзоны (UTC+13 и UTC-11), перевод часов как главный чит, конфиг поверх старого клиента, клейм наград ровно один раз, «запятая в конфиге = топ-меч за 1 монету», time travel на стейдже как must-have, kill switch и чек-лист запуска ивента.
-
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 пунктов.