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

14 ошибок TypeScript. Такой был результат моего первого промпта в ChatGPT, когда я попросил написать тесты для React-компонента.

Через несколько месяцев тот же запрос "напиши тесты" выполняет мультиагентный пайплайн из 7 AI-агентов. Он сам планирует тест-кейсы, пишет код, проверяет его по философии RTL, а потом намеренно ломает компонент, чтобы убедиться, что тесты не врут. 40+ компонентов уже прошли через него на проде.

Это история про путь между этими двумя точками. Без прикрас, с тупиками и неработающими подходами.

Даже с чистым кодом тесты могут падать с завидной нерегулярностью. Раз в десять прогонов, чаще в CI, чем локально. Не потому что CI какой-то особенный, а потому что там может быть меньше CPU, выше latency между сервисами и куча параллельных процессов. Асинхронные проблемы никуда не деваются и локально, но более мощная машина и быстрая сеть их маскируют. Стоит условиям стать чуть хуже, и тайминги разъезжаются: фронтенд уже отрисовал результат, бэкенд ещё обрабатывает запрос, а транзакция в базу ещё не закоммичена. Тест идёт проверять и не находит там того, что ожидает.

Три темы, которые дают стабильность на больших числах:

В дашборде было 83 успешных engagement’а. В аналитике X — 16 настоящих ответов. Пять к одному. Неделю я этого не замечал.

Контекст: у меня автономный AI-агент, который пишет комментарии в X (Twitter) от имени клиентов. Находит релевантные треды, генерирует ответ, публикует через браузер. Без моего участия. Ну, предполагается что без моего участия.

Матрица трассируемости (RTM) — инструмент, который помогает QA видеть реальное покрытие требований и не тестировать «вслепую».

В статье разберём:
• что такое RTM и зачем она нужна
• какие бывают типы трассируемости
• как выглядит матрица на практике
• типичные ошибки при работе с RTM

примеры таблиц, схемы и чек-лист для QA

Привет! Меня зовут Михаил Федоров, я руковожу центром компетенций QA. Мы решили не нанимать ещё двух тестировщиков, а написать систему AI-агентов, которая берёт на себя 80% рутины QA-инженера – от анализа требований до Merge Request с готовыми автотестами. В этой статье расскажу, как устроена архитектура, какие грабли мы собрали, и что из этого вышло на практике.

«Кроилово ведёт к попадалову» — знает каждый русскоязычный, поляк бы сказал — «Tanie mięso psy jedzą», в британских колониях прозвучит — «Penny wise, pound foolish»...

Это история о том, к чему приводит экономия на SMM персонале и незнание банального
«Quis custodiet ipsos custodes?»

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. Поехали!