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

Ошибка линтера стоит пяти минут. Ошибка сканера, который проверяет сайты на соответствие 152-ФЗ, выглядит иначе: «ваш сайт нарушает закон». Если сайт при этом в порядке, а отчёт уже ушёл клиенту, расплачивается чужая репутация.

Мы пишем такой сканер. Отчёт по нему получает не владелец сайта, а веб‑студия, которая ведёт сотню клиентских сайтов, и дальше отдаёт его клиенту под своим логотипом. То есть за нашу выдуманную находку краснеть будет она.

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

Я в тестировании много лет. И чем дальше, тем отчетливее понимаю: наибольшая проблема не в том, чтобы найти баг, а в том, чтобы поддерживать сценарии тестирования в актуальном состоянии. Начинал я с ручных сценариев в TMS, потом были Selenium, Cypress, Playwright. Казалось, автоматизация решит проблему. Но она ее просто перекладывает. Вместо того, чтобы щелкать кейсы руками, ты пишешь код, чинишь селекторы и разбираешься, почему тест, который вчера проходил, сегодня мистическим образом падает. А на фоне вечное «надо катить в прод прямо сейчас, в идеале вчера». Тесты всегда оказываются в конце списка приоритетов: их пишут в спешке, а поддерживают по остаточному принципу, еще ладно бы свои. Обиднее, когда достаются унаследованные со времен царя Гороха, написанные другими людьми и под другую архитектуру. За годы я писал и поддерживал, наверное, тысячи тестов — ручных и автоматизированных. И все это время меня не покидало ощущение, что процесс можно сделать легче. 

В общем, устав от постоянной гонки за качеством продукта при постоянном отсутствии времени, я задумался о поиске супер-пупер-тулы, которая будет писать тесты сама (в идеале, чтобы и сама запускала). Разумеется, с ростом популярности нейросетей возник вопрос: «А что, если всю работу целиком от сценария до тестирования будет выполнять машина?». Воспользовавшись тем, что такого решения еще нет, мы с моим коллегой @JSK решили: а давайте его изобретем? Спойлер: дело закончилось патентом.

С весны мы публикуем ежемесячный индекс активности IT-найма – раздельно по вакансиям РФ и США. Даже если взять короткий срок наблюдений всего в 6 месяцев, можно увидеть значительное отличие в трендах.

Как работать с коллекциями в Http API‑клиенте...

В клиенте уже год как работал экспорт коллекции как патча — одного JSON‑файла с операциями вида upsertRequest / removeRequest / setCollectionMeta. Достаточно, чтобы переслать коллеге точечное изменение: поправил заголовок в одном запросе — экспортировал — коллега применил патч у себя. Рабочая штука для передачи «из рук в руки».

Ниже — история одной конкретной фичи: зачем понадобился «git‑friendly» экспорт коллекции, как устроена стабильная сериализация и разрешение коллизий имён файлов, и какую дыру в защите секретов мы нашли и закрыли по пути. Без сравнений с другими клиентами — только то, что случилось и что мы с этим сделали.

Мы делаем пет-проект «Чатограмма»: он считает статистику переписки прямо в браузере, файл с перепиской на сервер не уходит. Такое обещание проще всего проверить без чтения политик: включить авиарежим и посмотреть, посчитается ли. Для этого странице нужно ответить на, казалось бы, тривиальный вопрос: есть ли сейчас сеть? На iPhone ответ оказался неожиданным.

Когда у функции на базе языковой модели нет одного правильного ответа, привычные проверки по принципу «ожидание = фактический результат» перестают работать. Тестировщику приходится определить, какие свойства ответа действительно важны, как отделить допустимую вариативность от ошибки и построить понятный критерий pass/fail.

В этой статье на примере функции суммаризации обращений разберём, как сформировать контракт поведения, набор проверок и подход к регрессионному тестированию AI-фич.

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

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

На очередном регрессе он снова зелёный.

Формально всё хорошо. Но зелёный результат подтверждает старую проверку, а не обязательно текущее требование.

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

Для этого и нужна трассировка требований.

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

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

Как мы справились с этой задачей и попутно разработали новый QA-инструмент на основе Agentic AI?

YApi — платформа документации API, мок-сервера и тестов с 27 тысячами звёзд — не обновлялась с 2022 года. На новом Node.js у неё ломаются токены, клиент не собирается, нужное ей расширение браузера больше не работает в Chrome, а мок-скрипты позволяют выполнить код на сервере.

Я продолжил проект и по дороге нашёл, что без настройки passsalt токены проектов шифруются общеизвестным ключом — участник проекта может выдать себя за другого пользователя. В статье — как это исправлено без поломки старых токенов, песочница для скриптов на isolated-vm, своё расширение на Manifest V3 и тест обновления на настоящей базе YApi.

Q, хабряне! На связи Максим Тучков, инженер по разработке ПО в YADRO. Сегодня я хочу вам рассказать о тестировании T-RAID — одного из центральных компонентов семейства СХД TATLIN. Пройдем путь от тестирования на виртуальных машинах с легковесным образом до комплексного системного тестирования на железном окружении. Вместе разберемся, сколько требуется QA-инженеров, чтобы уверенно сказать: «T-RAID работает как надо».

Мой опыт включает изолированное тестирование T-RAID и его проверку в составе комплексных релизов СХД TATLIN.UNIFIED. За моими плечами вклад в компонентное, интеграционное, системное тестирования, тестирование производительности и проверку сервисных процедур продукта. Из раза в раз новая область тестирования открывала для меня не столько новый принцип взаимодействия с T-RAID, сколько новые критерии приемки, инструменты и сценарии тестирования. Я проследил, как меняется тестирование T-RAID на каждом из уровней, и собрал свой опыт в этой статье.

Перевод статьи о QA-трансформации в крупном брокере: от ручных проверок к умному workflow. История о том, как тестирование было перестроено вокруг LLM: реальный стек, примеры пропущенных требований и разбор того, где ИИ ошибается. И да, человек всё ещё очень нужен.

Привет! Меня зовут Александр Чернышев, я занимаюсь тестированием мобильных приложений hh.ru, и за последние полгода моя рабочая рутина кардинально поменялась благодаря ИИ-инструментам, которые мы активно используем в HeadHunter. В моём случае это Claude Code с моделью Opus 5 — по моему опыту, она лучше всего справляется с рабочими задачами. Оговорюсь: у меня подписка Max, поэтому лимитов хватает с запасом. Сейчас я подключаю агента к большинству своих задач. Основа рабочего процесса — это скиллы: инструкции, которые задают агенту последовательность действий и не дают ему каждый раз импровизировать. Вместе с ними я использую MCP-серверы и плагины, через которые агент может взаимодействовать с внешними инструментами, например с Figma (figma-mcp).

В этой статье я разберу весь жизненный цикл задачи — от подготовки чеклиста и сверки с ТЗ до ретеста и автотестов — и покажу, как на каждом этапе использую ИИ-агента. Расскажу, какие локальные и корпоративные скиллы и MCP помогают мне в работе и что в итоге всё равно остаётся на стороне тестировщика.

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

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

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

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

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

Но практика показывает, что наладить такое общение может оказаться на удивление нетривиальной задачей. Чем мощнее становится инфраструктура, тем больше становится тестов, и время полноценного запуска по-прежнему измеряется часами. А код растёт и изменяется всё быстрее из-за ИИ, поэтому проверять приходится всё чаще.

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

В этой статье я запущу тестовую сюиту на стеке JUnit + Gradle + GitHub Actions, и опробую различные способы перезапуска конкретных тестов в ней.

Привет, Хабр! Меня зовут Михаил Новотарский, в Сбере я руковожу внедрением ИИ-практик в трайбе внутренних продуктов Workspace примерно на тысячу человек, а ещё развиваю профессиональное сообщество тестировщиков.

За карьеру я успел побыть почти во всех ролях, которые есть в QA: ручное тестирование, автоматизация, full stack и менеджмент. Поэтому мне особенно интересно наблюдать, как меняется сама профессия, и хочется обсудить, изменится ли её роль в будущем. Чтобы поговорить об этом предметно, введём персонажа — QA-киберагента. Это тестировщик, который не боится нового, постоянно развивает свои навыки и пытается понять, что будет дальше.

В статье разберем, как через LFR-уязвимость во внешнем сервисе облачной инфраструктуры удалось полностью скомпрометировать облако.

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

TLDR: забанили трёхлетний аккаунт с подпиской Pro, кибер‑доступом Daybreak Blue и вследствии: доступ ко всей накопленной информации в аккаунте — утерян.

Салют! Много‑много лет читаю Хабр, но сейчас специально зарегистрировался, чтобы рассказать маленькую историю, которая возможно поможет клиентам OpenAI избежать моей участи.

Приступим.

Жил да был аккаунт OpenAI с 2023 года. Сначала, он был бесплатный, совсем маленький. Потом подрос и пошёл в школу с ежемесячной оплатой в $20. К 2026 году аккаунт совсем возмужал и обросся подпиской Pro за $100 в месяц. Не тужил, от слова.

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

Одна точка в Gmail — и для сервиса перед вами уже другой пользователь. Мы наткнулись на это случайно, а потом решили проверить, насколько далеко можно зайти.

Привет, меня зовут Евгений Когтев, я руководитель направления разработки в команде дизайн-системы «LUNA» в Домклик. Расскажу про то, как у нас появилась идея упростить создание тестов с помощью Codegen: просто ходишь по сайту, как обычный пользователь, а в соседнем окне послушно рождается аккуратный, подсвеченный синтаксисом код. Никакой магии — сплошная инженерия, подумали мы.