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

Postman используют миллионы разработчиков — и не зря. Удобный интерфейс, коллекции, окружения, командный доступ. О чём еще мечтать?

Но если вы большую часть дня проводите в IDE, у этого подхода есть один постоянный friction point: нужно переключаться. Открыть Postman, вспомнить, где нужный запрос, скопировать токен из консоли, вставить руками. Потом вернуться обратно. И так по кругу.

В этой статье разберем альтернативный HTTP-клиент, который встроен прямо в IDE и его возможности для тестирования API.

В статье разобраны основные группы мероприятий, из которых состоит процесс тестирования. Вы узнаете:

▪️ чем отличаются тестовые условия от тест-кейсов,
▪️ зачем нужны таблицы решений и попарное тестирование,
▪️ как мониторинг и контроль помогают в общем процессе,
▪️ почему ретроспектива тестирования так же важна, как и планирование.

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

Привет всем, я Надежда Дудник, главный инженер по тестированию в Сбере, ментор по тестированию ПО и автор канала по тестированию @protestinginfo.

Хочу вам рассказать о важности написания хорошо структурированных тестовых сценариев на примере стратегии их составления для бэкенда.

Всем привет! Я Лина, инженер по обеспечению качества в Команде Контента и Трафика в Банки.ру.

Я хочу рассказать, как мы работали над обновлением сложного сервиса – Народными рейтингами. В этой статье представлен каждый шаг от макетов до пострелизного теста: со своими заметками, выводами и, конечно, примерами конкретных багов, которые попадались во время работы над новыми Народными рейтингами и редизайном НРСК.  

Здесь мы рассматриваем фабрики в тестировании. На очень элементарных примерах, с использованием языка 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 в команде оформлений. Моя команда занимается процессингом оформления кандидатов во всю группу компаний. Поделюсь докладом моей коллеги — Марии Палагиной из команды разработки веб-платформ об автоматических релизах. 

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

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

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

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

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

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

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

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

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

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

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