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

Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова.

Почему команды не тащат нагрузку в релизный цикл? Потому что это чаще всего просто не окупается: нужно выбрать движок, описать сценарий, гонять тесты вручную или тратить время на создание собственной обвязки для встраивания в CI, придумать критерии качества и анализировать результаты. Всё это занимает значительное время, а на короткой дистанции часто оказывается оверинжинирингом. Но если формирование требований упростить концептуально невозможно, то всё остальное вполне можно собрать в переиспользуемый инструмент, позволяющий командам легко интегрировать нагрузочное тестирование и регрессионный анализ в свой процесс доставки.

В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе.

Развернём нагрузочное тестирование на своих мощностях. Без ДД (долго, дорого). k6, VPS, сценарий на JavaScript, метрики в Grafana Cloud. Полчаса на настройку и встраивание в CI/CD. Для тестировщиков, разработчиков и всех, у кого есть пет-проекты.

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

В сложном веб-интерфейсе пользовательское действие редко заканчивается на одном контроле. Клик меняет состояние. Состояние формирует параметры. Параметры уходят в связанный компонент или в запрос. Компонент пересчитывает данные, обновляет разметку, перерисовывает таблицу, диаграмму или модальное окно. Если один шаг в этой цепочке выпадает, интерфейс может выглядеть рабочим, но функция уже выполняется неправильно.

На примере Modus BI разберём пять багов, которые нашли с помощью ручного тестирования. Это не история про «кликнуть по кнопке и сверить текст». Каждый кейс показывает конкретный тип логической проблемы...

У каждого автотестера, наверное, есть такая идея, которая крутится в голове годами. Ты понимаешь, что она должна работать, но всё время не до неё: текущие задачи, дедлайны, «и так сойдёт».

У меня такой идеей было реализовать вменяемое ожидание готовности страницы. Не конкретного элемента — а страницы целиком. В один прекрасный момент мне предоставилась такая возможность...

Привет, Хабр! Меня зовут Юра Жанов, я занимаюсь автоматизацией тестирования в hh.ru.

Про flaky-тесты написано много, борьбу с ними не прекращаем и мы. Но сегодня немного о другом — хочу поделиться нашим опытом минимизации неприятностей, которые наносят такие тесты. Для этого мы провели ряд экспериментов со стороны тестового фреймворка.

TL;DR: Sentry дедуплицирует backend‑ошибки по хешу (error class + top stack frame + module). Для UI‑багов этот рецепт ломается — у expect(button).toBeVisible() нет stack frame в продуктовом смысле, есть локатор + assertion + URL. В webtest‑orch я собрал composite SHA-256 fingerprint из (normalized_selector | assertion type | error class | URL template | message[:80]) с тремя rules нормализации (:nth-child, UUID, /users/123 → /users/:id). Это даёт стабильный 8-hex BUG-id который выживает прогоны и даёт diff new / regression / persisting / fixed без БД и embedding«ов.»

Прежде чем рассуждать о потенциале развития Дополненной реальности (AR) в 2026 году, попробуем разобраться в чем же ее отличие от Виртуальной реальности (VR) и почему последняя в ближайшие годы точно не будет интересна бизнесу.

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

Форк репозитория — операция настолько привычная, что на нее редко смотрят с подозрением. Но что, если через обычный форк можно запустить произвольный код на CI/CD-воркере чужой приватной компании? 

Именно такую цепочку мы обнаружили в GitFlic — отечественной платформе для совместной разработки ПО и хранения исходного кода от компании «РеСолют». 

GitFlic во многом похож на GitLab — что логично, ведь создавался как его альтернатива. И получилось у разработчиков сносно: если вы работали с GitLab, то GitFlic вызовет у вас приятное чувство дежавю.

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

Обнаруженные нами уязвимости были оперативно исправлены разработчиками компании «РеСолют» и зарегистрированы в БДУ ФСТЭК: BDU:2025-12462, BDU:2025-12463, BDU:2025-12464.

Теги: product management, risk management, marketplace, telecom, customer experience, pre-mortem

Коротко о главном

У меня возникла идея для сервиса Интуицын — предзапусковую репетицию риска. Он превращает спорное коммерческое решение (изменение тарифа, новые правила для партнёров, комиссия за способ оплаты, ребрендинг) в карту риска: кто отреагирует, насколько это материально, через какие каналы пойдёт распространение недовольства и что можно изменить до публичного контакта с рынком.

В этой части (1 из 2) — продуктовый и аналитический разбор без технических деталей. Я покажу, как сервис отработал на 3 реальных кейсах из недавней истории российского рынка: тарифы у мобильных операторов, штрафы для партнёров маркетплейса и одновременный ребрендинг с запуском премиального направления. Два из трёх кейсов в реальности закончились публичным конфликтом, действиями ФАС, забастовкой партнёров или их сочетанием. Третий — на бумаге выглядел как идеальный кандидат на скандал и был так помечен сравнительным baseline-прогнозом обычной языковой модели — но в реальности прошёл без материального ущерба. Сервис правильно отранжировал материальные кейсы в верхней части риска, а спорный «двойной» — в нижней, и всё это до того, как ему сообщили исход.

Сервис проверяли на двух последовательных ретроспективных слепых прогонах: первый — 6 кейсов, расширенный — 20, всего 26 кейсов российского рынка. Cуммарно когортный слой правильно классифицировал 26 из 26 исходов; обычный сравнительный baseline-прогноз большой языковой моделью — 22 из 26, в остальных 4 случаях принял громкий, но переносимый негатив за материальный провал. На последнем 20-кейсовом расширении ранжирование разделило набор без ошибок: верхние 10 — все материальные кейсы, нижние 10 — все без материального ущерба. Это пилотный сигнал, а не финальное доказательство.

Представьте себе «Матрицу» – сервис, где создана иллюзия безопасности путем обмана пользователей. Через юридидические документы, которые должны защищать пользователей, но по факту все наоборот: они защищают создателя сервиса.

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

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

12340 анкет, 24 тысячи чужих файлов на 7 GB – все оказалось доступным без единого взлома.

Результат – весьма неожиданный…

У каждого второго разработчика или QA есть сервис, который написан на древней версии языка, не имеет авторов, тесты не работают, документация — одна страница, но он стабильно работает, и его все боятся трогать.

А потом прилетает задача: добавить мультиязычность, или новый тип данных, или интеграцию с внешним API. И вы понимаете: либо вы его трогаете сейчас, либо он ломается сам через полгода в самый неподходящий момент.

Нам в Иви "повезло" оказаться именно в такой ситуации. Поэтому делимся своим кейсом по тестированию и обновлению SEO-сервиса — без пафоса, с шишками, метриками и выводами, которые реально помогут.

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

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

Больно видеть, как много появляется на рынке таких продуктов, прошедших технические проверки и проваливших испытание пользовательским опытом. Идеально работающих, но никому не нужных. Что делать, чтобы не войти в их число?

Задача была простая: протестировать два веб-приложения перед деплоем. Next.js-портфолио и SaaS-чат — accessibility, консольные ошибки, отзывчивость на мобильных. Рутина.

Открыл Claude Code, подключил Playwright MCP, написал «протестируй приложение». Агент начал работать, делать скриншоты, проверять элементы. На 51-м снапшоте /compact сработал. Текстовый контекст был заполнен на 18%. Я не понял что произошло.

Через час разбирательств я нашёл невидимый image-лимит. Через три часа — понял, что Playwright MCP сжигает в 50 раз больше токенов чем CLI на том же workflow. Через три дня — у меня был рабочий инструмент, который уже тестируют реальные пользователи.

Эта статья — про путь от «хочу просто протестировать» до open-source инструмента, и про архитектурные проблемы, которые заставили его собрать.

В каждой профессии есть ритуал инициации, о котором не принято говорить вслух. У хирургов — первая ночная смена с тяжёлым пациентом. У пилотов — посадка вслепую на тренажёре. У багхантеров и пентестеров есть Карлос. Да, тот самый Carlos, чей пароль или токен вы будете выгрызать из экзаменационного приложения PortSwigger, пока где-то на фоне тикает таймер, а Burp Collaborator хранит гробовое молчание.

Меня зовут Султан. Первая попытка, два часа — экзамен сдан.

Я знаю, о чём вы подумали: сдать BSCP с первого раза удаётся очень немногим, даже опытным специалистам. Так почему у меня получилось? Ответ — в методологии.

Я не буду рассказывать о вещах, которые и так известны абсолютному большинству. Раскрывать все уязвимости из экзамена смысла нет: существует около сотни различных комбинаций, запомнить их все невозможно.

У меня школа тестировщиков. SQL — обязательный блок, потому что без него на собеседовании в любую серьёзную компанию делать нечего, и в реальной работе тестировщику регулярно нужно залезать в базу. На рынке уже существуют (хоть и не так много) SQL‑тренажеры, но мне хотелось сделать удобнее и иметь возможность полностью управлять сервисом и адаптировать под наши нужды. Собственно, ниже, моя разработка.

В разработке качество часто ломается не только на самих багах — но и в тех местах, где работа переходит от одного этапа к другому без ясных условий. Задача уже поехала дальше, хотя acceptance criteria ещё сырые. Формально её можно тестировать, но по факту сначала нужно собирать контекст. Пайплайн зелёный, при этом важная проверка вообще осталась за его пределами.

Такие ситуации обычно показывают не частную ошибку, а устройство процесса в целом. Когда важные условия нигде не закреплены, команда расплачивается за это уточнениями, возвратами и лишней синхронизацией. И напротив — если критерии перехода определены заранее, работать проще. Поэтому Quality Gates для нас в Островке — не только способ ничего не упустить, но и понятный маркер того, насколько процесс разработки вообще выстроен и управляем. 

Форма у таких гейтов может быть разной: автоматическая проверка, правило в workflow или простой критерий готовности. Важно не как выглядит гейт, а какую точку неопределённости он закрывает.

Под катом — практический разбор того, что вообще можно считать Quality Gate, где такие механизмы реально работают и как подбирать их под задачи команды.

Привет! Меня зовут Артем Русов. Около 6 лет я занимаюсь обучением будущих теcтировщиков на платформах Stepik, Udemy и YouTube. И каждый день получаю вопросы о том: что там с тестированием и стоит ли начинать его изучать сейчас?

Сам я не смогу дать однозначный ответ: да или нет. Так что предлагаю ознакомиться с этой статьей всем заинтересованным, а уже в конце для себя принять окончательное решение.

Привет! Меня зовут Оля Шнайдер, я QA-инженер в Авито. В начале этого года я провела исследование рынка QA, чтобы понять, как сейчас работают тестировщики: с чем сталкиваются каждый день, что мешает в работе, а что, наоборот, помогает.

За последние годы роль QA заметно изменилась (или мне так хочется думать). От нас ждут большего — не только непосредственно тестирования и ответственности за результат, но и участия в процессах и много чего ещё. При этом сами процессы не всегда становятся лучше. 

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

Redis всё чаще встречается в вакансиях для QA, и понимание его работы становится полезным навыком для тестировщика.

В статье простым языком объясняется, что такое Redis, где он используется, чем отличается от реляционных баз данных и почему он работает быстрее SQL.

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

Подойдёт для подготовки к собеседованиям и для работы на реальных проектах.