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

Здесь мы рассматриваем фабрики в тестировании. На очень элементарных примерах, с использованием языка python и инструментов Django, pytest, factory_boy.

JMX-файл на 50 000 строк, merge-конфликты при каждом коммите и PR-ревью, которое никто не читает - знакомо? Я столкнулся с этим на реальном проекте и нашёл способ декомпозировать JMeter-тесты так, чтобы основной файл похудел в 10 раз, а работать с тестами стало можно прямо из IDE.

Если вы уже имели опыт написания Ul-тестов для проверки страниц и форм, то, вероятно, задумывались: "Почему бы не протестировать весь сценарий целиком?" Так родилась идея делиться опытом, как мы внедрили подобный подход: начиная с первых шагов, объясняя, почему объединили UI, АРІ и SSH в единый интеграционный контур, и какие инструменты используем.

В первой части был заложен фундамент: локаторы, «умные» ассерты и хелсчеки. Это критически важные вещи, но на масштабе в 100+ тестов неизбежно возникает «второй слой» проблем — сложность диагностики и изоляция данных.

Неделю назад по сети пронеслась новость о том, что генеральный директор Y Combinator Гарри Тан с помощью ИИ Claude пишет десятки тысяч строк кода ежедневно и имеет виртуальную команду из 10+ ролей. Я решил проверить насколько это решение действительно рабочее и не является ли оно очередным хайпом. В этой статье мы разберемся, что за инструмент использует CEO Y Combinator и в чем его особенности. А также попрактикуемся в его использовании.

Так как типичная LLM обучена работать с  текстом, первые попытки были просто давать модели чистый HTML. И как не странно, это даже работало, причём надёжнее, чем ожидалось скептиками.  

Одновременно в параллельной вселенной существовали E2E тесты, которые имитировали живых юзеров, нажимали на кнопки и заполняли поля. И этим тестам тоже как-то надо было отслеживать изменения на экране. Сравнение скиншотов оказалось крайне не надёжным методом. Тут разработчики Playwright – это известный open source фреймворк для E2E тестов, под крылом Microsoft - вспомнили про  ARIA и экранные читалки.

Пришёл в команду, открыл тесты — should render, снэпшоты, CSS-классы в ассертах. CI зелёный, покрытие растёт. Всё хорошо? Нет. Тесты падали при любом рефакторинге, но пропускали реальные баги в логике. Ложная уверенность, которая хуже отсутствия тестов. И проблема была не в отдельных файлах — а в самом инструменте, который провоцировал так писать.

Проблема не в том, что инструментов мало. Проблема в том, что большинство из них построены вокруг браузера прошлого поколения, тогда как frontend уже давно живёт внутри runtime. Именно из этой практической боли появился собственный runtime-инспектор — сначала как консольный скрипт для одной конкретной задачи, а затем как полноценный инструмент, который неожиданно нашел отклик у QA и разработчиков.

Сегодня разберём реальный кейс пентеста крупного российского банка. Поговорим о том, как двухфакторная аутентификация превратилась в иллюзию безопасности, и что делать, чтобы ваша защита не была такой же. Речь пойдёт не о сложных zero‑day эксплоитах, а о банальной ошибке, которая до сих пор встречается. Мы посмотрим, как 4 цифры в SMS и отсутствие лимитов открыли доступ к паспортам, документам и финансовым заявкам. И главное — разберём, как закрыть эту дыру ещё на этапе проектирования.

Ваши тесты стабильно проходят локально, но в CI каждое утро — красный океан? Вы тратите часы на дебаг флаков, а стейджинг «ложится» в самый неподходящий момент? Знакомо? В этом гайде расскажу, как перестать жечь бюджет CI и превратить автотесты из источника боли в живую документацию, следуя методологии BDR (Behavior-Driven Living Requirements).

Почему это важно:
Если у вас уже 100+ тестов или вы только закладываете фундамент — неправильная архитектура будет стоить команде десятков часов дебага и простоя CI. Но есть проверенные практики, которые внедряются за пару часов и экономят деньги каждый день.

Вы узнаете:

Как использовать Dependency Projects вместо globalSetup, чтобы строить граф иммунитета и экономить 40 минут CI при падении окружения.

Почему авторизация через API — это база, а UI-логин должен быть только в одном тесте.

Как выбирать локаторы, чтобы не переписывать тесты после каждого апдейта фронтенда: getByTestId для действий, getByRole для проверок.

Почему isVisible() — зло, и как web-first assertions (с ретраями) убивают race conditions.

В чём ловушка гидратации и почему force: true — это маскировка проблемы, а не решение.

Как блокировать маркетинговый мусор (метрики, чаты), чтобы тесты не зависели от сторонних тормозов.

Как Trace Viewer превращает дебаг из гадания в машину времени: смотрим не просто скриншоты, а консоль, сеть и интерактивный DOM в момент падения.

Прагматичный подход к линтерам: что включать как error, а что — как warn, чтобы не перегнуть палку.

Для кого:
Для QA-инженеров, которые хотят поднять свои тесты на промышленный уровень. Для тимлидов, которые устали от горящего CI и хотят стандартизировать подход в команде. Для всех, кто использует Playwright и хочет спать спокойно.

Бонус:
Cheat sheet по web-first ассертам, шпаргалка частых флаков и готовые конфиги для playwright.config.ts и .eslintrc.js. А в конце — челлендж: примените 5 правил уже сегодня и оцените стабильность.

Часть 1 — фундамент стабильности. В следующей части разберём масштабирование: фикстуры, изоляцию данных, параллельный запуск и превращение тестов в живую документацию.

Подход и код — в открытом репозитории на GitHub. Поехали!

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

Автоматические релизы — не просто модное словосочетание. Это мощный инструмент, который может кардинально изменить подход команды к выпуску новых версий продукта. 

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

Привет, Хабр! На связи разработчик Куратов Кирилл из команды дирекции качества РТЛабс. Представлю вам нашу внутреннюю разработку — User Pool.

По названию понятно, что это пул пользователей, но глобально он представляет собой сервис для получения данных тестовых учётных записей. Наша команда использует User Pool во фреймворке для написания автотестов и в браузерном расширении для автоматической авторизации тестовых учётных записей в тестируемых сервисах. Например, в единой системе идентификации и аутентификации (ЕСИА), речь о которой пойдёт ниже. Также в конце будет небольшая история о том, как мы разрабатывали расширение для браузера и с какими трудностями столкнулись.

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

Я ненавижу писать фронтовые тесты. Не потому что я против тестирования, а потому что в какой-то момент они превращаются в бессмысленный ритуал. Особенно когда от тебя требуют покрыть ими вообще всё.

Привет, хабровчане!

Мы команда «Исходного кода» и уже полгода системно занимаемся нагрузочным тестированием (НТ). Раньше такие проверки были от случая к случаю - оттуда и взяли базу знаний. Сегодня хотим поделиться историей одного показательного фейла, который заставил нас пересмотреть весь подход и прийти к системе, которая показала себя, как работающая. 

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

Главный толчок был простой и жизненный: уже на стадии рассмотрения сервиса мы понимаем, какая нагрузка на него ляжет, поэтому мы выводили правило: «Сервис должен стабильно держать N запросов в секунду», и мы берем эту планку и начинаем работу.

Про то, как автоматизация тестирования сначала даёт максимальный профит, а потом незаметно превращается в дорогой технический долг. И почему это почти всегда вопрос не инструментов, а подхода.

Прокси — один из основных инструментов в арсенале QA-инженера. Charles Proxy, Fiddler и Proxyman давно стали стандартом для анализа и изменения сетевого трафика в процессе ручного тестирования. Их принцип работы хорошо известен и подробно описан во множестве материалов.

Однако возникает вопрос: как использовать подобные возможности в UI-автотестах? Как перехватывать или мокать трафик в автоматизированных сценариях?

Зачем нужны covers метки? Почему их так хочется сломать? Как это сделать? Рассказ будет извилист, но идея проста: улучшить навигацию, не задев покрытие.

В стартапе на стадии Pre-Seed/Seed вы либо фанатично считаете деньги, либо умираете. В RankCaster AI мы уперлись в классическую ловушку масштабирования: больше фич = больше людей в QA = раздутый COGS и медленные релизы.

Регрессионный анализ каждого апдейта занимал до 48 часов ручного труда. Мы решили, что платить за «прокликивание» дашбордов в 2026 году — это грех, и собрали автономного AI-агента, который делает это лучше человека.

Привет, Хабр! Меня зовут Александр, я из Сбера, лидер по автоматизации в Департаменте Сервисы и Безопасности. В тестировании я около 13 лет, и последние лет 10 занимаюсь автоматизацией и её развитием в своём подразделении.

В этой статье расскажу, как с помощью IDE, LLM и RAG‑подхода можно автоматизировать одну из самых рутинных задач автоматизаторов — разработку новых автотестов по ручным сценариям, и при этом сохранять стиль и архитектуру проекта.