Тестирование веб-сервисов *

Интеграционные тесты любят все на словах, пока не доходит до окружения, зависимостей и плясок с подготовкой стенда. В статье разберем более практичный подход: как писать изолированные интеграционные тесты с Testcontainers, не превращая их в хрупкую конструкцию из моков и костылей. На примере PostgreSQL и .NET посмотрим, как собрать тестовую среду, которая ведет себя достаточно близко к реальности, но при этом остается воспроизводимой и управляемой. Тема не новая, а боль до сих пор вполне живая — так что давайте разбираться.

Как устроен процесс собеседования QA-инженера в 2026 году? Из каких этапов он состоит и чем интересуются интервьюеры на каждом из них? В этом гайде я разложил всё по полочкам: что спрашивает HR (и как он оценивает ваши ответы), какие блоки теории нужно повторить manual-инженерам, а какие — automation-инженерам на Java, и как проходит секция с задачами на логику и лайвкодингом.

Внутри — структурированные списки вопросов с разбивкой по темам, реальные примеры из практики и советы, как правильно "продать" себя на каждом этапе. Материал будет полезен как джунам, так и опытным специалистам для систематизации знаний.

Рынок QA больше не про «быстрый вход» и простые решения. Вакансий меньше, требований больше, а старые советы не работают. В статье — приземлённый алгоритм, который помогает начать путь от рынка, а не от обещаний, и не потратить год на подготовку без выхода к офферам.

Как тестировать микросервисы, чтобы не было мучительно больно на проде? Разбираем пирамиду тестирования, интеграционные тесты с Testcontainers, контракты с Pact и нагрузочные испытания. Расскажу, какие практики реально работают в крупных проектах...

Хабр, привет!

На связи Леонид Дьячков, в Positive Technologies мы с командой специализируемся на безопасности смарт-контрактов и блокчейн-приложений. Наша экспертиза охватывает полный спектр задач: от глубокого криптоанализа и проектирования кастомных фаззинг-кампаний до разработки и применения формальных методов верификации. Мы работаем на стыке кода, математики и бизнес-логики Web3-протоколов, выявляя неочевидные векторы атак и системные риски. 

Обычно в отрасли много внимания уделяется экосистеме EVM (Ethereum Virtual Machine, виртуальная машина Ethereum), но в этой статье мы целенаправленно разбираем приватный блокчейн Hyperledger Fabric, потому что он важен для корпоративных сценариев, так как позволяет допускать к сети только авторизованных участников, управлять их идентификацией и изолировать данные на уровне каналов.

Git — это вызов, через который проходит каждый второй новичок в разработке. Ветки называются «asdasd», коммиты — «правки», а pull request пугает своей красной кнопкой. Знакомо?

Меня зовут Сергей Прощаев, я Tech Lead в FinTech и преподаватель на курсах в OTUS. В этой статье разбираем самое главное: как создавать ветки и почему их нельзя называть как попало, что писать в коммитах, как сделать pull request в лучших практиках команд разработки

Как часто вы задумывались о нагрузочном тестировании (НТ), когда на подходе очередной релиз, но времени на дополнительные проверки катастрофически не хватает? В таких условиях НТ обычно выглядит ненужной роскошью, но на деле оно — неотъемлемая часть процесса, которой нельзя пренебрегать. Нагрузочное тестирование помогает избежать множества рисков, особенно в условиях роста количества пользователей и требований к производительности.

Мы — команда QA из РТЛабс. В этой статье мы расскажем, как с помощью опенсорс-инструментов создать надёжную и масштабируемую инфраструктуру для НТ, осуществлять запуск тестов в один клик, организовать высокопроизводительный мониторинг в реальном времени и долгосрочное хранение результатов.

Поиск работы в IT часто выглядит похожим образом: десятки откликов, постоянные собеседования, новые команды, разные проекты и условия.

На старте карьеры я довольно быстро столкнулся с проблемой, о которой сейчас регулярно слышу и от других специалистов.

Собеседований много, информация начинает смешиваться. По итогу в голове остаётся только одно — предложенная зарплата.

В результате решение об оффере принимается почти вслепую.

Через пару недель после выхода на работу внезапно оказывается, что процессы совсем не такие, как ожидалось, задачи другие, команда работает по-другому, а уровень нагрузки отличается от того, что представлялось на интервью.

За время регулярных выходов на рынок я выработал несколько простых практик, которые позволяют существенно снизить вероятность подобных сюрпризов.

Поделюсь основными из них, надеюсь, что всем будет полезно 👇

У Playwright неплохие трейсы, но приходится перезапускать тест каждый раз. Исправил, перезапустил, упало, смотришь логи. И так по кругу, пока не заработает.

Хотелось бы менять часть кода «на лету», без перезапуска всего теста, прямо в редакторе Visual Studio Code. Чтобы синтаксис проверялся, tslinter‘ы всякие работали, автодополнение и прочий AI. Напечатал

await page.getByRole("search", {name : "Search"});

 Выделил строчку и запустил. Посмотрел на реакцию, поправил

 await page.getByRole("searchbox", {name : "Search"});

Запустил снова. И так много раз, если надо. Можно несколько команд сразу запускать, если хочется. Модули импортировать на лету. Чтобы scope запоминался, если выполнил

Большинство API-тестов бесполезны: они флакают и тормозят CI. Показываю альтернативу — изоляционные тесты без стендов и боли.

В конце прошлого года написал статью про то, почему я выбрал Suno, чтобы написать шутливый музыкальный альбом для поднятия настроения коллегам-айтишниками А сейчас я хочу раскрыть вопрос, как я это сделал.

Расскажу про рабочие пространства (Workspace), редактор (Editor) и как их можно применять.

Рассмотрим с вами артефакты генераций и как они исправляются с наглядными примерами.

Поделюсь некоторыми итогами и идеями про ИИ-генераторы (в первую очередь Suno)

Привет! Я Ангелина Архипова, тимлид QA в Авито. Это вторая часть статьи про развитие QA, ранее я разобрала этапы взросления QA-инженера — от охотника за багами до лидера, который формирует культуру качества в команде.

Когда смотришь на эти этапы со стороны, они часто кажутся абстрактными: вроде бы понятно, что должно измениться, но не всегда ясно, как к этому прийти на практике. Какие инструменты действительно помогают расти? На что стоит тратить время, а что можно смело отложить? И как не застрять на одном этапе, даже если формально ты уже «сеньор»?

В этой статье я хочу перейти от теории к практике и разобрать инструменты и подходы, которые помогают QA-инженеру развиваться осознанно. Мы посмотрим, какие из них полезны на разных этапах, как они влияют на мышление и почему сами по себе инструменты ничего не решают — важно то, как и зачем ты их используешь.

Меня зовут Павел Коростин, я техлид тестирования мобильного банка для юридических лиц в Альфа-Банке. Бэкенд мобильного банка — это около 300 микросервисов, работающих в k8s, развитием которых занимаются примерно 50 команд, разделённых на функциональные области. За каждой командой закреплены сервисы, которые они поддерживают, разрабатывают, тестируют и, соответственно, пишут автотесты. Раньше все тесты на сервисы «жили» в одном монорепозитории, но в определённый момент мы поняли, что дальше так работать уже не можем и нужно как-то разъезжаться.

Не буду вдаваться в подробности, почему гигантский монорепозиторий неудобен, потому что, если вы уже решили избавляться от громоздкого монолита, то основной вопрос — как дробить?

Раз в несколько месяцев я вижу одни и те же обсуждения:
«Manual QA больше не нужны»,
«Рынок перегрет»,
«Всё автоматизируют и заменят».

Если коротко — нет, QA никуда не исчезает.
Но профессия действительно сильно меняется. И тем, кто работает в тестировании, важно понимать в какую сторону.

В этой статье расскажу. Что нужно делать, чтобы не остаться у мусорки без работы 👇

Привет! Меня зовут Николай Олигеров, я работаю продуктовым аналитиком в Яндекс Путешествиях. В этой статье я расскажу, как мы применяли PSM (Propensity Score Matching) — статистический метод, который позволяет корректно сравнивать группы, уменьшая систематические различия между ними. Подробно разберу, как выровнять группы теста и контроля с помощью PSM, расскажу о типичных ошибках (например, утечке признаков), дам практические рекомендации по сбору и выбору фич для мэтчинга, а также покажу, как валидировать полученные результаты и оценить их достоверность.

Почти 800 тестов, 10 минут на прогон, каждый пуш — ожидание на CI. Знакомо? Рассказываю, как довёл время до 101 секунды: снижение таймаутов, параллелизм ScalaTest, shared Testcontainers и защита от регрессий. Scala, SBT, PostgreSQL, GraalVM — конкретные шаги и подводные камни.

Когда я только начинал свой путь в автоматизации, мне отчаянно не хватало толкового и структурированного материала по паттернам проектирования именно для автотестов. Хороших статей про паттерны в целом — вагон, а вот с привязкой к тестированию — днём с огнём не сыщешь.

Паттерны — это та вещь, которая моментально выдает уровень культуры кода и понимание инженерных практик. Неудивительно, что на собеседованиях на позицию Automation QA любят покопаться в этой теме.

В этой статье я решил закрыть этот пробел. Вы найдете не только продуманную классификацию основных паттернов автоматизации, но и самый подробный, на мой взгляд, разбор каждого из них с примерами. А в конце поговорим про антипаттерны.

Добро пожаловать в обсуждение! Буду рад конструктивной критике и дополнениям.

HTTP простыми словами. Часть 1 (Основы).

Статья для тех, кто хочет разобраться в основах протокола. Рассматриваются методы HTTP, форматы запросов и ответов, URI/URL, версии протокола, заголовки и коды состояния.

Материал содержит схемы и примеры, включая ручную сборку HTTP-запроса и отправку через PowerShell. Подойдёт начинающим разработчикам (фронтенд, бэкенд), тестировщикам и всем, кто работает с веб-технологиями.

Первая часть цикла – в следующих статьях будет разобран жизненный цикл HTTP-соединения.

Привет, Хабр! Это четвёртая статья из серии про QA собеседования. Уже разобрали тест-дизайн, API и Security и System Design. Теперь — SQL. На собеседованиях SQL задают чаще, чем многие ожидают. Не уровня DBA, но и не SELECT * FROM users. Обычно дают таблицу и просят написать запрос прямо на доске или в Google Docs. Если впадаете в ступор при слове JOIN — эта статья для вас.

Вы попросили ChatGPT добавить скидку 10% на заказы больше $100. Он выдал 40 строк кода. Скидка работает - проверили на заказе в $150, получили $135. Закоммитили.

Чего вы не заметили: модель переписала функцию расчёта цены целиком. Не потому что нужно было. Просто так получилось - LLM не "редактирует" код, он генерирует новый текст на основе вашего промпта и контекста. В процессе он изменил порядок вычисления налога. Заказы меньше $100 теперь считают налог дважды. Товар за $10 стоит $10.80 вместо $10.50. Вы узнаете об этом через три недели, когда клиент напишет в поддержку.