Все статьи
122 статей
-
Верстка под разные экраны: вырезы, safe area, складные и масштаб шрифта
Твой телефон — одно устройство из тысяч. Разбираем, что ломается на разных соотношениях сторон, вырезах, складных экранах и при шрифте 200%, и как это тестировать. С чек-листом.
-
Как тестировщику работать с Claude: рабочий процесс, а не игрушка
Claude экономит часы на рутине QA — если работать с ним как с младшим коллегой, а не как с поисковиком. Разбор рабочего процесса, задач и границ доверия.
-
Промпты для QA: шаблоны, которые реально экономят время
Формула хорошего промпта и семь готовых шаблонов для типовых задач тестировщика — от генерации тест-кейсов до анализа логов и ревью требований.
-
Выгорание в 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, частичная загрузка, устаревшие данные, ошибка на догрузке; доступность пустых и ошибочных состояний и компактный чек-лист.
-
Краши и ANR в мобильной игре: как ловить то, что у тебя не воспроизводится
Краши почти никогда не падают на твоём девайсе — они живут на чужих, где мало памяти и рвётся сеть. Разбор от первого лица: почему сначала нужно тестировать сам репортер (реальный случай, где Crashlytics поднимался позже краша, а exception-handler забрал рекламный SDK), чем краш отличается от ANR, зачем символикация и контекст в отчёте, managed vs native краши в Unity и как намеренно воссоздать чужие условия.
-
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.
-
Тестирование runtime-разрешений в мобильном приложении: состояния, отзыв на лету и edge-кейсы
Разрешения — это не «дал/не дал», а матрица состояний. Модель из пяти состояний, pre-permission priming, graceful fallback на отказ, убийство процесса при отзыве на лету, background location и точная/приблизительная гео, ATT и limited Photos на iOS, «Don't ask again» на Android, проверка по трафику через Proxyman и чек-лист на 12 пунктов.
-
Observability для QA: логи, метрики, трейсы — что проверять и как пользоваться
Observability глазами тестировщика: три столпа (логи/метрики/трейсы) простым языком, как тестировать саму наблюдаемость (trace id, метрики, секреты в логах), как QA использует её для локализации распределённых багов и тихих деградаций, SLI/SLO/error budget и чек-лист observability-ready фичи.
-
Выгорание в QA: ранние признаки, причины и как вытащить себя и команду
Выгорание у тестировщиков: чем оно отличается от усталости (3 измерения по ВОЗ), почему QA в зоне риска, ранние признаки, три уровня причин (личные/командные/процессные), что реально помогает, что делать тимлиду и мини-чек-лист самопроверки.
-
AI-боты, которые сами играют в игру: автоматизация game-QA в 2026
AI-агенты для тестирования игр: чем отличаются от скриптовых автотестов, что реально умеют (exploratory 24/7, краши, баланс, видео-логи), где предел и риски, кто на рынке (modl.ai, AltTester, GameDriver), когда брать AI-ботов, а когда хватит обычной автоматизации. Чек-лист пилота.
-
Чек-лист тестирования загрузки файлов: 30+ кейсов, которые забывают
Переиспользуемый чек-лист тестирования file upload: содержимое vs расширение и magic bytes, размеры и decompression bomb, имена файлов и path traversal, процесс загрузки и обрыв сети, серверная обработка и хранилище, безопасность (SVG XSS, RCE, SSRF) и доступность. 30+ пунктов.
-
FTUE / онбординг в мобильной игре: что тестировать в первой сессии
Первая сессия (FTUE) глазами QA: матрица входов (установка/реинсталл/диплинк/логин), прерывания туториала, скип и обязательные шаги, вернувшийся игрок и апдейт, идемпотентная награда, A/B и аналитика воронки. Чек-лист на 12 пунктов.
-
Тестирование диплинков: deep links, Universal Links, App Links и матрица состояний
Диплинки глазами QA: три типа ссылок, матрица состояний (foreground/background/killed/не установлено), deferred deep linking и атрибуция, fallback и битые ссылки, безопасность, верификация AASA/assetlinks, инструменты adb/simctl/Proxyman. Чек-лист на 12 пунктов.
-
Мок-серверы для QA: WireMock и компания — когда подменять зависимость заглушкой
Когда внешнюю зависимость нельзя или не нужно поднимать реально — её мокают. Зачем мокать, что умеет хороший мок-сервер (стабы, fault injection, record/replay, verify), инструменты WireMock/MockServer/Mockoon/Prism/Hoverfly, мок vs Testcontainers, контрактный дрейф и Pact. Чек-лист на 10 пунктов.
-
Нагрузочное тестирование: как спроектировать и не получить мусорные цифры
Как делать load-тесты правильно: виды (load/stress/soak/spike/breakpoint), перцентили вместо средней, открытая vs закрытая модель, реалистичные данные и профиль трафика, серверные метрики и сатурация, coordinated omission, инструменты k6/Gatling/Locust/JMeter. Чек-лист на 12 пунктов.
-
Собеседование на QA в 2026: как готовиться и что реально спрашивают
Карта подготовки к собеседованию на QA: теория и техники тест-дизайна, severity vs priority, фреймворк ответа на «протестируй X», баг-репорт, API/SQL-минимум, автоматизация, поведенческие по STAR, красные флаги компании. Чек-лист на 10 пунктов.
-
Тестовые данные в автотестах: источник флака и связности — и как их готовить
Тестовые данные — один из самых незаметных источников flaky-тестов, сильнее локаторов. Изоляция, детерминизм (freeze clock, seeded Faker), уникальность в параллели, фабрики vs фикстуры vs API-setup, очистка и анонимизация прод-данных. Чек-лист на 12 пунктов.
-
Чек-лист тестирования форм: 30+ кейсов, которые забывают
Переиспользуемый чек-лист тестирования форм: текстовые поля и trim, валидация, числа и деньги, email/телефон/дата/пароль, маски и autofill, двойной сабмит и идемпотентность, сеть, безопасность и доступность ошибок. 30 пунктов + мини-шаблон.
-
Тестирование рекламы в мобильной игре: rewarded, interstitial, медиация и edge-кейсы
Монетизация рекламой глазами QA: как тестировать rewarded и interstitial, идемпотентность награды (SSV), no-fill, медиацию и waterfall, frequency capping, ATT/GDPR consent, сеть и аналитику. Чек-лист на 13 пунктов.
-
Testcontainers: реальные БД, Kafka и Redis в тестах вместо моков и общего стенда
Как тестировать интеграцию против настоящего Postgres, Kafka и Redis в Docker — без вранья моков и флакающего общего стенда. Wait strategies, reusable containers, Ryuk, модули, CI и чек-лист внедрения на 10 пунктов.
-
Knight Capital: как $440 млн испарились за 45 минут из-за одного деплоя
Разбор катастрофы 1 августа 2012 года глазами QA: переиспользованный feature-флаг, незамеченный 8-й сервер, мёртвый код Power Peg и 97 проигнорированных алертов. 7 уроков и чек-лист релиз-процесса на 10 пунктов.
-
Idempotency и retry-storms — что должен тестировать QA в distributed systems
Самый дорогой класс багов в payments — «прошло два раза». Гайд по идемпотентности глазами QA: Idempotency-Key, 5 типовых retry-сценариев, что такое retry storm, тулзы (WireMock, Toxiproxy, k6), чек-лист на 13 пунктов.
-
1-1 для QA — что готовить, шаблоны и как обсуждать рост с тимлидом
1-1 — инструмент твоего роста, не статус-репорт. 90% QA проводят 50 встреч в год впустую. 5 типов содержания, готовые формулировки для 5 болезненных тем (повышение, выгорание, конфликт), шаблон 1-1 doc и чек-лист подготовки.
-
Android-фрагментация для мобильной игры — что ломают MIUI, One UI, EMUI и battery savers Oppo/Vivo
«На Pixel работает, на Xiaomi падает, на Samsung другие баги, на Huawei нет Google Play.» Полный гайд по фрагментации 2026: 6 OEM с их quirks, что ломается в играх, минимум для QA-лаба, чек-лист и формат bug-репорта.
-
Claude в QA переоценён — 10 сценариев, где он подводит, и где реально окупается
В QA-комьюнити хайп: «Claude заменит мануальщика». На проде эти обещания не подтверждаются. Контрарианский разбор без anti-AI пафоса: 10 переоценённых сценариев, 5 системных ограничений, скрытые риски и 5 сценариев где реально работает.
-
CrowdStrike июль 2024 — как один драйвер за 78 минут уронил 8.5 млн Windows-машин
Самый дорогой software-failure в истории — $5.4 млрд прямого ущерба. Тривиальный off-by-one на стороне internal validator. Полный разбор timeline, root cause, три отдельных QA-провала и 10 уроков для своей команды.
-
OWASP API Security Top 10 для QA — гайд с тест-кейсами
Большинство QA знают про SQL injection и XSS. При этом 90% уязвимостей в современных продуктах живут в API, а OWASP API Top 10 2023 — отдельный список, в QA-курсах его не разбирают. Все 10 угроз с тест-кейсами, curl-запросами и инструментами.
-
Bad news стейкхолдерам — как QA сообщать релизные проблемы
Soft-skill, который отличает junior от senior. Большинство QA либо тянут до последнего, либо вываливают панику. 11 разделов: принципы, готовые шаблоны для 5 типовых ситуаций, каналы, эскалация, постмортем.
-
AI и auto-healing локаторы в автотестах — что реально работает в 2026
Half of mature autotest suite — это мейнтенанс локаторов. На этой боли построен класс продуктов под лейблом «AI-powered». 8 разделов: что под капотом auto-healing, Healenium vs Mabl/testRigor/Functionize, где LLM работает реально, риски и план внедрения.
-
Accessibility-чек-лист для мобильного приложения в 2026
28 июня 2025 в EU вступил в силу European Accessibility Act — для b2c-приложений a11y теперь юридическое требование. 11 разделов чек-листа: VoiceOver/TalkBack, Dynamic Type, контраст, touch targets, семантика, автотесты.
-
Cloud Save в мобильной игре — чек-лист тестирования
Игрок прошёл 30 уровней на iPad, открыл iPhone — прогресса нет. Это самая дорогая в репутации часть мобильной игры. 9 разделов и чек-лист QA для cloud save: API, конфликты, кросс-платформа, corruption, восстановление.
-
API-тулы для QA в 2026 — Postman, Bruno, Insomnia, Hurl: что когда выбирать
Сравнение четырёх API-инструментов по параметрам, которые имеют значение в реальной QA-работе. Postman ушёл в облако, Bruno вырос как git-friendly альтернатива, Hurl закрыл CI-нишу.
-
Тестирование на плохую сеть — 8 сценариев и инструменты
Большинство QA-чеклистов покрывают только «интернет есть» и «Airplane mode». Реальные пользователи живут между ними. 8 сценариев деградации сети с инструментами и приёмочными тестами.
-
Junior → Middle → Senior QA: реальные сигналы роста на каждом уровне
Половина QA-инженеров застревает между уровнями на 1–2 года. Не потому что мало знают — а потому что не понимают, чего от них ждут на следующей ступени. Разбор по уровням: что ждут, чего НЕ ждут, сигналы готовности, антипаттерны, чек-лист самооценки.
-
5 видов тестирования, которые покрывают 90% реальной работы
Видов тестирования десятки. На практике каждый день используются пять. Разбираемся с каждым: где применяется, что ловит, где ломается, какие ошибки чаще всего совершают.
-
Классический QA умирает. Что приходит на смену
Классический QA-подход опирался на простую идею — проверили перед релизом, можно доверять. Сегодня это перестало работать. Что нужно изменить в самом понимании качества.
-
Visual Regression тестирование: гайд от А до Я
Функциональный тест зелёный, кнопка кликается, форма отправляется — а юзер смотрит на экран и видит, что иконка съехала на 4 пикселя влево и наезжает на текст. Классический разрыв между unit/E2E-те...
-
Claude для тестировщика: 10 реальных сценариев и промпты
AI-ассистенты быстро прошли путь от «забавной игрушки» до полноценного рабочего инструмента. Для QA-инженеров это особенно мощно: рутинные задачи типа генерации тест-кейсов, разбора логов, написани...
-
Push-уведомления: чек-лист тестирования из 10 секций
Push-уведомления — один из самых недотестируемых классов фич. На QA-чек-листе обычно «пришёл / не пришёл», а реальных кейсов десятки: permission states, разные состояния приложения, deep linking, D...
-
Тестирование In-App Purchase в мобильной игре: 9 разделов и чек-лист
IAP — самый дорогой сегмент кода для бага. Один пропущенный кейс «деньги списались, но товар не пришёл» — это support-тикеты, рефанды, плохие отзывы и удержание под угрозой. И при этом IAP покрытие...
-
Maestro vs Appium: что выбрать для UI-тестов мобильной игры в 2026
Appium держит трон с 2014 года, но если ты сейчас выбираешь стек для мобильных UI-тестов — посмотри на Maestro. Проще ставится, проще пишется, и в casual-проектах часто покрывает 100% нужного.
-
Proxyman для QA: гайд по перехвату и подмене HTTP-трафика
HTTP/HTTPS-трафик между приложением и сервером — самый частый источник трудноуловимых багов: аналитика, IAP, реклама, remote config, A/B-тесты, push-уведомления. Если вы всё это тестируете «по UI»...
-
Mars Climate Orbiter: $327 миллионов из-за фунтов и ньютонов
23 сентября 1999 года NASA потеряла космический аппарат на подлёте к Марсу. Не было аппаратной поломки. Это был бенчмарк-баг про интеграционное тестирование.
-
Performance тесты мобильной игры: 7 метрик, которые реально важно проверить
«Игра тормозит» — слишком абстрактно для тикета. Чтобы performance-проблема была воспроизводимой, измеряемой и трекабельной — нужны конкретные числа. Вот 7 метрик.
-
Playwright auto-wait: почему вам не нужны explicit waits
Если ты пришёл в Playwright из Selenium — первое инстинктивное движение писать waitForSelector перед каждым действием. В 90% случаев это лишняя работа: Playwright уже ждёт за тебя.
-
Чек-лист локализации: 10 ловушек, которые ловятся за один проход
Локализация — не «прогнать тексты через переводчика». На 5+ языках всплывает дюжина классов багов, невидимых на английском. Компактный чек-лист, покрывающий 90% реальных проблем.
-
Что эмулятор не покажет: 5 классов багов на реальном железе
Эмуляторы ускоряют CI и удобны для smoke-тестов, но опираться только на них — самообман. Часть проблем проявляется только на реальном девайсе с реальной нагрузкой и сенсорами.
-
Тест-пирамида устарела: чем её заменили крупные команды
Классическая пирамида Майка Кона (2009): много unit-тестов, средне integration, мало E2E. Модель родилась в эпоху тяжёлых UI-фреймворков. Сейчас баланс сместился — что используют вместо пирамиды.
-
Чек-лист тестирования полей с датой и временем
Поле «выберите дату» выглядит безобидно — но именно с датами и временем в продакшене проваливается больше всего проверок. Часовые пояса, переходы на летнее, локали, високосные года — каждый пункт уже стрелял в кого-то.
-
Почему ваши автотесты падают раз через раз: 5 причин flaky-тестов
Flaky-тесты — главный источник недоверия к автоматизации. По данным Google Testing Blog, около 1.5% всех зелёных пробегов в их CI содержали хотя бы один нестабильный фейл. И чаще всего проблема не в продукте, а в самом тесте.
-
SQL для QA: базовые запросы которые реально нужны
SQL — must-have навык для QA. Не сложный, но без него каждое исследование бага упирается в «спрошу у разработчиков». 10 запросов хватит для 80% работы.
-
Bug Bash: как организовать продуктивную сессию
Bug bash — когда вся команда тестирует продукт за 2 часа. Делается раз в спринт. Но половина команд делает его впустую.
-
Переход junior → middle QA: что отличает и что нужно прокачать
Junior — это входной билет. Middle — это уверенный профессионал. Что меняется и какие 7 навыков отличают.
-
Public speaking для QA: как презентовать результаты команде
QA приходит к концу спринта с результатами — а команда не слышит. Не потому что не интересно, а потому что плохо подано. 5 правил.
-
ChatGPT vs Claude для тестировщика: практическое сравнение
Оба умеют генерировать тест-кейсы и анализировать логи. Но для разных задач один лучше другого. Сравнение на реальных QA-задачах.
-
AI-генерация тест-кейсов: как использовать без потери качества
ChatGPT и Claude могут сгенерировать 50 тест-кейсов за минуту. Но половина — будет шаблонная вода. Как получить РЕАЛЬНО полезные кейсы.
-
JWT-токены: что должен проверять QA
JWT — стандарт авторизации в современных приложениях. Базовый набор тестов и атак, которые должен знать каждый тестировщик.
-
OWASP Top 10 для тестировщика: что должен знать каждый QA
Security testing — не только pentest. Базовые уязвимости из OWASP Top 10 должен уметь проверять каждый QA. Не доверять разработке.
-
Выгорание в QA: симптомы и профилактика
QA — одна из топ-профессий по выгоранию в IT. Однообразие, давление дедлайнов, бесконечная регрессия. Как распознать и что делать.
-
Code review глазами QA: что искать когда не разработчик
QA не обязан читать каждую строку кода. Но в code review он может найти то, что разработчики пропускают.
-
QA-метрики которые НЕ работают: список и чем заменить
Bugs/sprint, test coverage, defect density — все звучит научно. На практике многие QA-метрики либо бесполезные, либо вредные.
-
Risk-Based Testing: как приоритезировать тесты по риску
Покрыть всё — нереально. Приоритезация по риску — единственный разумный подход когда времени мало. Как это делать систематически.
-
Test Plan vs Test Strategy: разница, которую важно понимать
Эти два документа путают, объединяют, переименовывают друг в друга. На самом деле у них разная аудитория, разный scope и разный жизненный цикл.
-
Definition of Done для QA: чек-лист готовности фичи
Когда фича «готова»? Это не философский вопрос — это конкретный чек-лист. Что должно быть выполнено перед закрытием тикета.
-
Priority vs Severity: разница которую путает половина QA
Два поля в баг-репорте, одни и те же значения (High/Medium/Low), но смысл разный. Когда какое использовать.
-
k6 vs JMeter: что выбрать для нагрузочного тестирования в 2026
JMeter — классика 20+ лет. k6 — современный претендент. Сравнение для команд которые выбирают сейчас.
-
JMeter: пошагово для первого нагрузочного теста
Нужно проверить выдержит ли API 1000 пользователей? JMeter — рабочий тул для этого. Гайд от нуля до первого результата.
-
Jenkins для QA: основные паттерны построения пайплайна
Jenkins — старичок CI, но его всё ещё используют в половине корпоративных проектов. Как QA-инженеру построить пайплайн без боли.
-
Postman vs Bruno vs Insomnia: что выбрать для API тестирования
Postman доминировал 10 лет, но в 2024 ввёл cloud-обязательность и потерял доверие. Какие альтернативы есть сейчас.
-
Матрица в CI: какие версии браузеров и ОС реально тестировать
«Тестируем во всех браузерах» — звучит хорошо, но в реальности матрица из 50 комбинаций × 200 тестов = 30 часов CI. Как разумно ограничить покрытие.
-
Параллелизация автотестов: 5 ловушек, которые превращают её в ад
Параллелить тесты — очевидное решение для ускорения CI. Но если не учесть несколько вещей, получишь flaky-тесты, гонки за данные и потерю детерминированности.
-
Headless vs headed браузер в CI: что выбрать
Headless экономит ресурсы, headed помогает отлаживать. В чём разница на практике и какие баги ловит только один из режимов.
-
REST API тестирование на Python: pytest + requests за час
Если ты ручной тестировщик и хочешь начать автоматизировать API — это самый низкий порог входа. Что нужно знать.
-
BDD vs TDD vs ATDD: когда что использовать в QA
Три аббревиатуры, которые часто путают. Разбираем кратко: что это, чем отличаются, и какая подходит вашей команде.
-
Page Object Pattern в 2026: классика, эволюция и когда не нужен
Page Object — самый известный паттерн в автоматизации UI-тестов. Но за 20 лет существования он эволюционировал. Что использовать сегодня.
-
App Store / Play Store review: за что отказывают и как пройти с первого раза
Отказ от Apple — это 1-2 недели задержки релиза. Список самых частых причин и как их избежать на стороне QA.
-
Тестирование биометрии: Face ID, Touch ID, fingerprint
Биометрия выглядит просто — приложил палец, вошёл. На самом деле UX содержит десятки edge cases. Что обязательно проверить.
-
Background tasks на iOS и Android: что должен проверять QA
Приложение свёрнули — что с фоновыми задачами? Загрузка ассетов, синхронизация, аналитика — всё это может молча умереть в фоне. Что тестировать.
-
App Permissions: lifecycle и edge cases которые пропускают
Запросы доступа к камере, локации, контактам — самый недотестированный класс мобильных фич. Что проверять и в каком порядке.
-
Deep linking в мобильном приложении: что и как тестировать
Deep link открывает приложение на конкретном экране. Звучит просто — но реальных кейсов десятки. Чек-лист тестировщика для проверки deep linking на iOS и Android.
-
Playwright: с чего начать и где учиться
Playwright стал стандартом веб-автоматизации в 2023-2025 годах. Подборка ресурсов, которые помогут перейти на него с Selenium/Cypress или начать с нуля.
-
adb для мобильного QA: 40 команд, которые экономят часы
ADB (Android Debug Bridge) — главный инструмент мобильного QA на Android. Собрал список команд, которые реально используются на регрессе и при разборе багов.
-
5 книг, которые стоит прочитать тестировщику
QA как профессия имеет свою классическую литературу — её знают все senior-инженеры. Если ещё не читал — стоит закрыть пробел. Подборка из 5 книг, которые сформировали современный подход к тестированию.
-
Английский для QA: где учить бесплатно и без боли
QA-инженер без английского — это ограничение карьеры. Документация, лучшие книги, доклады, общение с командой за рубежом — всё на английском. Подборка ресурсов, которыми реально пользуются.