Статьи
Здесь собраны материалы, которые я писал и дорабатывал годами: практические разборы, инженерные выводы и сильные технические статьи по QA Automation, Go, Python, TypeScript, API, UI, нагрузочному тестированию, AI и тестовой инфраструктуре.
По таким фильтрам статей не нашлось.
Интернет завален историями о том, как собрать SaaS за выходные через Cursor под бокал вина. Но почему ИИ-агенты обесценили код, но так и не породили миллионы новых стартаперов? Разбираемся, почему вайбкодеры путают работающий прототип с реальным бизнесом, и как вместо компании мечты вы рискуете собрать себе вторую работу — без зарплаты, отпусков и начальника, на которого можно свалить ответственность.
Я дал шести топовым AI-моделям один и тот же промпт: сгенерировать API-автотесты на Python, pytest и httpx. На первый взгляд результат похож на нормальную автоматизацию, но при разборе видно: слабая проверка контракта, мягкие статус-коды, плохая диагностика, мало расширяемости и много предположений вместо требований.
Часто под «нагрузочным тестированием» понимают всё подряд — и в итоге проверяют не то, что нужно. В статье разбираю виды performance testing и объясняю, когда использовать load, stress, spike, soak и chaos testing на практике.
Почему большинство нагрузочных тестов (load testing) не имеют смысла: разберём, как моделировать реальное поведение пользователей, а не просто генерировать запросы.
Разбираем ключевые метрики нагрузочного тестирования: RPS, latency, percentiles (P95, P99), error rate и другие. Показываю, как правильно их интерпретировать, почему average вводит в заблуждение и как по метрикам понять реальное поведение системы под нагрузкой.
История о том, как мой аккаунт на Habr заблокировали после 3,5 лет публикаций, почему я экстренно эвакуировал весь архив статей на свой сайт и какие выводы сделал о чужих площадках, модерации, ИИ, рекламе и независимости автора.
Почему отчётность, статистика и логирование в Go-автотестах превращаются в костыли — и как плагинная модель позволяет вынести инфраструктуру за пределы тестов.
На примере FastAPI-чата показываю, как выстроить автотесты для API с двумя транспортами: REST используется для подготовки состояния, WebSocket — для проверки событий. В статье разбираем архитектуру тестов на Python: клиенты, фикстуры, Pydantic-схемы, контрактные проверки, Allure и CI/CD.
Flaky-тесты в Go — неизбежны, но наивные ретраи делают только хуже. Разбираем, почему retry — это не цикл и как правильно реализовать повторный запуск автотестов.
Не каждый сценарий, который можно покрыть автотестом, выгодно автоматизировать. Разбираю, какие тесты чаще всего не окупаются, почему длинные и хрупкие E2E быстро превращаются в источник затрат и как смотреть на автоматизацию с точки зрения бизнеса.
Компании редко заставляют перерабатывать напрямую. Они просто создают условия, в которых уйти вовремя становится почти стыдно: релиз горит, команда ждёт, баг не воспроизводится, бизнесу нужно “сегодня”. Разбираемся, как это работает и почему героизм инженеров часто становится бесплатной заменой нормальному менеджменту.
testing в Go даёт только примитивы. Разбираем, почему автотесты в Go быстро превращаются в боль, и какого слоя исполнения в нём не хватает.
Разбираемся с терминологией Test Doubles без лишней воды. В чем реальная разница между Mock, Stub и Fake? В статье разберем классификацию на живых примерах: поднимем умный стаб-сервер на FastAPI, напишем мок-шпион для проверки сайд-эффектов и ускорим тесты с помощью фейковых БД.
«70% кода написано с AI» звучит красиво в отчёте. Но почему это не делает продукт быстрее? Разбираем главную подмену понятий в текущем AI-хайпе.
Мы попытались построить MCP-сервер, который сам читает спеки, пишет автотесты и коммитит код. На практике выяснилось, что токены — не главная проблема, а QA — это не «делатели тестов», а носители контекста и ответственности.
Я делал AI Review как простой инженерный инструмент. Но реальный фейл оказался не в архитектуре и не в LLM — а в том, чего люди от него ждали.
Рынок QA изменился: конкуренция выросла, требования стали жёстче, а старые сценарии входа больше не работают. В статье — честный разбор рынка, требований и иллюзий, которые до сих пор продают новичкам.
Большинство UI-тестов флакают, медленно работают и в итоге отключаются в CI. Показываю альтернативу — изоляционные UI-тесты без стендов, таймингов и боли.
В Go нет фикстур, и в интеграционных тестах это быстро превращается в копипаст. Разбираем, как вынести инфраструктуру из автотестов и управлять жизненным циклом ресурсов.
Созвоны ломаются, VPN отваливается, сообщения теряются. Мы просто хотели рабочий чат — и в итоге сменили мессенджер. Рассказываю, что получилось.
Почему найм в IT стал жёстким, как фейковые резюме и AI убили доверие, и почему в 2026 году легче не станет.
«Нам нужен сотрудник с горящими глазами» — звучит красиво. Но часто за этой фразой скрывается ожидание постоянного героизма, размытые границы ответственности и системные переработки. Где заканчивается вовлечённость и начинается эксплуатация — разбираемся без эмоций и иллюзий.
Про то, как автоматизация тестирования сначала даёт максимальный профит, а потом незаметно превращается в дорогой технический долг. И почему это почти всегда вопрос не инструментов, а подхода.
Рынок QA больше не про «быстрый вход» и простые решения. Вакансий меньше, требований больше, а старые советы не работают. В статье — приземлённый алгоритм, который помогает начать путь от рынка, а не от обещаний, и не потратить год на подготовку без выхода к офферам.
Большинство API-тестов бесполезны: они флакают и тормозят CI. Показываю альтернативу — изоляционные тесты без стендов и боли.
Личные наблюдения о бездумном использовании AI: почему vibe coding не делает разработчиков сильнее, как исчезает экспертиза и где AI реально полезен, а где нет.
Бесплатные адвенты, «практика в реальных условиях», «с нуля до PRO», тысячи отзывов и наград. Разбираю типовую модель, по которой в 2026 году продают иллюзию входа в QA — и почему она редко приводит к реальной работе.
Почему одни кандидаты проваливаются из-за одной фразы, а другие проходят дальше, даже без идеальных ответов? Семь реальных подводных камней собеседований, о которых обычно узнают слишком поздно.
Почему стандартные процессы найма делают собеседования предсказуемыми, как на этом зарабатывают и что с этим можно сделать без войны и моралей.
Как писать «скучные» API-автотесты на Go: выносим всю инфраструктуру в Axiom , оставляя в тестах только бизнес-сценарии, и запускаем всё в CI/CD с Allure.
«Сколько платят в QA» — вопрос не про цифры, а про роль. Анализ зарплат QA-вакансий за 2025 год по данным 2500 объявлений показывает, почему manual и junior остаются в нижнем сегменте рынка, а automation и fullstack-специалисты получают существенно больше.
Рынок QA давно вышел за пределы «тестирования кнопок». Анализ 2500 вакансий показывает, какие технологии сегодня считаются базовым минимумом — и почему этот минимум далеко не junior-уровня.
Анализ 2500 QA-вакансий за год показывает, почему junior и manual-позиции почти не формируют спрос и на кого рынок QA реально ориентирован в 2026 году.
Axiom — это недостающий тестовый runtime для Go, который добавляет фикстуры, шаги, хуки, retry, плагины, метаданные и структурированное выполнение поверх стандартного testing, оставаясь полностью совместимым с ним. Минимум магии, максимум инфраструктуры.
В этой статье я собрал девять самых частых задач из live-coding этапов собеседований на Python — от декораторов и замыканий до GIL и паттернов. Эти задачи регулярно встречаются в компаниях разного уровня, и их знают те, кто часто участвует в найме. Мы разберём каждую задачу: как её формулируют интервьюеры, какие типичные ошибки делают кандидаты, и как выглядит корректное решение с пояснениями. Цель статьи простая — помочь разобраться в базовых механизмах Python, которые важны как на собеседованиях, так и в реальной работе.
ИИ фактически обнулил модель «эксперта, который знает всё». Почему исчез поток джун-вопросов, куда делась токсичность и что теперь считается настоящей экспертностью — разбираю на примерах.
Почему оффер ломается не на алгоритме, а на вопросе «кем вы видите себя через 5 лет?» — разбираю шесть таких ловушек и показываю сильные ответы.
Почему автотесты становятся нестабильными и перестают приносить пользу? Разбираем системные причины флаков, бессмысленных ретраев и бесконечных E2E-монстров. Практические принципы: моки, изоляция, атомарность и минимализм — без философии, только инженерия.
Лучших инженеров увольняют не потому, что они плохи. А потому что они слишком правы. Их слова рушат иллюзию контроля — и показывают, что план не сработает. Но без них компании быстро понимают, какой ценой даётся это «спокойствие».
В этом материале я покажу, как всего за 30 минут встроить в ваш CI/CD пайплайн полноценное AI-кодревью и ассистента на базе открытого инструмента AI Review — без платных API и лишней инфраструктуры.
Этот инструмент экономил сотни тысяч долларов и без него нельзя было выпустить релиз — но на бумаге оставался “пет-проектом” одного инженера. Почему компании раз за разом убивают такие инициативы — и как этого избежать.
Как за полчаса подключить автоматическое ревью кода с помощью AI Review и локальной LLM Ollama прямо в CI/CD — без токенов и VPN.
Раньше вас ревьюил злой коллега — теперь это делает AI. AI Review — open-source инструмент, который сам проверяет код прямо в CI/CD. Поддерживает OpenAI, Claude, Gemini, GitLab и GitHub. Быстро, честно и без боли.
Разбираем самые странные антипаттерны в автотестах на Python: от sleep(0.1) и стрелочек вниз до глобальных курсоров и "фреймворков" на 3500 строк. Почему так делать не стоит и какие есть взрослые альтернативы.
Асинхронность в тестах выглядит как способ «бесплатно» ускорить прогон: пока один тест ждёт ответа сервера, другой мог бы выполняться. Я переписал UI (Playwright) и API (HTTPX) тесты на async/await, прогнал их в CI/CD и посмотрели на результат. Спойлер: магического ускорения не произошло — разбираемся, почему так и когда асинхронность всё-таки нужна.
Что происходит с QA-индустрией и куда она движется? Действительно ли профессия умирает или у неё есть будущее?
Почему ваши нагрузочные тесты врут? Часто проблема не в коде и не в стенде, а в данных. Разбираемся, как правильно готовить окружение перед тестами и почему сидинг через API надёжнее прямых вставок в БД.
«ChatGPT убьёт тестировщиков» — миф или реальность? Рассказываю, как AI уже влияет на сферу QA и почему инженеры не останутся без работы.
Как выбрать профиль нагрузки, чтобы результаты тестирования имели смысл? Разбираем 5 практических правил, основанных на SLA, данных с продакшена и прогнозах роста, и объясняем, почему важно учитывать не только клиентские, но и системные метрики.
Оверинжиниринг — это когда простую задачу решают так, словно строят космический корабль: с абстракциями, фабриками и паттернами «на будущее». Разбираем живые примеры, почему так происходит и как находить баланс между гибкостью и простотой.
Разбираем 10 удобных конструкций Python, которые помогают писать код короче и понятнее: list и dict comprehension, zip, enumerate, f-строки, Pathlib и другие полезные приёмы. Особенно полезно начинающим разработчикам.
Пошаговое руководство для Manual QA, которые хотят перейти в автоматизацию. Как выбрать направление, язык и инструменты, какие шаги пройти и что добавить в портфолио, чтобы уверенно расти в Automation QA.
Начинающие автоматизаторы часто наступают на одни и те же грабли: от отсутствия параметризации до связанных автотестов. В этой статье — разбор ошибок и советы, как писать тесты так, чтобы они жили долго и стабильно.
У него в резюме Python, Playwright, Pytest, Jenkins, Docker, Kafka, GitHub, GitLab, и он вёл QA-гильдию в Третьем Царстве. А потом пришёл на собес — и не смог объяснить, чем отличается UI-тест от интеграционного. Мы дали задачу. Он попытался её решить. Мы все плакали. Он — тоже.
Разбираемся, как организовать нагрузочное тестирование на Python с Locust — с сидинговыми сценариями , кастомными API-клиентами на HTTPX, конфигурацией через Pydantic и автоматическим запуском в GitHub Actions . Всё — на практике, с архитектурой, фреймворком и публикацией отчётов в GitHub Pages.
По фактам: почему CSS и XPath — путь в ад, а test-id — спасение. В статье — реальные советы, как договориться с командой, внедрить test-id и писать автотесты, которые не разваливаются каждую пятницу.
В этой статье — без прикрас и маркетинговой мишуры. Жестко, честно и по фактам рассказываю, как устроены мошеннические курсы в тестировании (и не только), как вас обманывают, и на что стоит обращать внимание, чтобы не слить деньги впустую.
В статье разбираем современный подход к автоматизации тестирования — от требований до продакшена. Как писать автотесты ещё до выката фичи, запускать их в изоляции, работать в одной ветке с разработчиком и ловить баги раньше, чем они попадут на стенд. Реальные практики, понятные схемы и причины, почему "автоматизация после релиза" — путь в никуда.
Покрытие UI-тестами — вещь, о которой все говорят, но почти никто не измеряет. А если и измеряет, то по старинке, через Excel, TMS или на глаз. Это как считать шаги, не надевая шагомер. ui-coverage-scenario-tool — это как шагомер, но для UI-тестов. Он показывает, с чем именно взаимодействуют ваши тесты, что осталось в тени, и главное — делает это автоматически. Без ручного труда, без вымышленных цифр, без «по ощущениям». Это не очередной инструмент ради красивого дашборда. Это инструмент, который ставит зеркало перед вашим UI-покрытием — и показывает, есть ли там что-то, кроме отражения.
Как понять, что реально делают ваши UI автотесты? ui-coverage-tool — это инновационный инструмент нового поколения, не имеющий аналогов. Он визуализирует покрытие прямо в браузере, работая с реальным приложением. История по каждому элементу, фильтры по действиям, динамика и полная наглядность — всё, чтобы не просто тестировать, а понимать и улучшать.
Разбираем, как писать масштабируемые и читаемые UI автотесты на Python с использованием паттернов PageObject , PageFactory и PageComponent . Разберем на атомы как устроены эти подходы, когда их применять и чем они отличаются. Всё это — на примере тестового проекта UI Course с CI/CD и наглядными отчетами в Allure .
В этой статье я расскажу про swagger-coverage-tool — инструмент, который показывает, насколько полно ваши тесты покрывают API по спецификации Swagger (OpenAPI). Всё работает автоматически, без изменений в логике тестов. Поддерживаются httpx и requests , отчёт генерируется в один клик. Идеально, если вы хотите объективно видеть, что действительно проверяют ваши API автотесты.
Почему в вакансиях для джунов требуют 3 года опыта? Как неадекватные требования, массовые курсы и бюрократия убивают рынок найма? Личный опыт, наблюдения и немного сарказма о том, как не попасть в ловушку сомнительных вакансий.
В этой статье разберём процесс написания API автотестов на Python, используя современные best practices. Кроме того, мы настроим их запуск в CI/CD с помощью GitHub Actions и сформируем Allure-отчёт с историей запусков. Цель статьи — не только показать, как писать качественные API автотесты, но и научить запускать их в CI/CD, получая удобные отчёты о результатах.
Как провалить собеседование в IT? Легко! Провел больше сотни интервью и заметил закономерности, из-за которых кандидаты получают отказы. В этой статье — субъективные, но проверенные советы для опытных специалистов, которые хотят проходить собесы легче. Даже если у вас "богатый" бэкграунд, вопросы к вашему опыту могут появиться внезапно и поставить в тупик. Делюсь наблюдениями, разбором типичных ошибок и рекомендациями, которые помогут взглянуть на процесс глазами собеседующего.
Load-testing-hub : эволюция сервиса аналитики нагрузочного тестирования Ранее я рассказывал о load-testing-hub , инструменте для аналитики и агрегации данных по нагрузочным тестам. Тогда он находился в стадии MVP , а теперь прошел значительные улучшения. Что изменилось? — Добавлено больше информации и гибкости в настройках. — Расширены возможности сравнения результатов. — Реализованы детальные графики и аналитика по методам. — Оптимизирован процесс выявления аномалий в производительности сервисов. Один из практических кейсов — поиск по банковским операциям среди сотен миллионов записей. Load-testing-hub помог протестировать производительность, выявить узкие места и оптимизировать решение. Изменений настолько много, что проще рассказать о сервисе заново. В статье подробно разберу его новые возможности и кейсы использования.
В этой статье расскажу о сервисе QA Admin , который разработал с нуля для нашей компании. Основная цель сервиса — упростить подготовку тестовых данных и сократить время, необходимое на тестирование.
В данной статье хочу рассказать про инструмент измерения покрытия gRPC сервисов tests-coverage-tool , написанный на языке Golang . Основная задача инструмента — автоматическое измерение покрытия требований на основе proto контрактов. Поговорим про использование в автотестах, концепцию, отчет и кратко про архитектуру самого инструмента tests-coverage-tool .
В данной статье хочу рассказать про сервис load-testing-hub , главная задача которого это сбор, агррегация, анализ и визуализация данных о нагрузочном тестировании Расскажу о том, какие проблемы решает сервис, как он помогает оценивать производительность выпускаемых релизов, а также поделюсь примерами его использования Рассмотрим основные возможности load-testing-hub , такие как создание наглядных графиков и отчетов, сравнение результатов нагрузочных тестов
В данной статье разберем, как писать gRPC автотесты с использованием языка Go, также сделаем Allure отчет.
В данной статье разберём, как писать API автотесты на TypeScript и Playwright, применяя лучшие практики автоматизации.
Пишем UI автотесты на TypeScript используя Page Object, Page Component, Page Factory, Playwright, Allure.
Как правильно писать API авто тесты на Python используя Pytest, Pydantic, Httpx, Allure.
Как правильно писать UI авто тесты на python используя Playwright, Page Object, Page Component, Page Factory.
Введите запрос, чтобы найти нужные материалы на сайте.