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

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

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

У TenChat нет публичного API для публикации постов. Отложенная публикация в самом сервисе есть только на платном тарифе (на 28.09.2026 от 990 ₽ в месяц), а мне нужен был простой сценарий: раз в день берём следующую статью из блога, собираем из неё короткий пост с обложкой и выкладываем без участия человека. Я написал для этого скрипт на Python и Playwright, он работает на сервере по cron с конца сентября 2026 года. В статье разберу, как скрипт входит в аккаунт без пароля, как заставить редактор Quill принять готовую вёрстку, чем завершились первые недели и какие грабли попались при переезде с ноутбука на сервер.

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

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

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

Или все-таки ПО в кризисе?

Корпоративный сайт на пяти языках: около сотни страниц, блог, новости и 100–150 тысяч пользователей в месяц. Два года он жил на Webflow. Переезд на Next.js 15 и Payload CMS сейчас на финишной прямой, и шёл он без дня Х: страница за страницей, на одном домене со старым сайтом.

Разбираю, как это устроено. Счёт Webflow по строкам, Next.js под /app на Webflow Cloud и 301-редиректы с пятью локалями, перенос CMS-коллекций в Lexical, next-intl и проверки в CI, которые ловят то, что раньше находил только дизайнер через месяц.

Всем привет! Меня зовут Костя, я QA-инженер в Банки.ру. Общение с агентом у меня давно стало обыденным делом. И в какой-то момент я заметил, что работа тестировщика превратилась в ежедневное объяснение ему одного и того же: «прочти задачу», «составь критерии приёмки», «сделай баг-репорт», «сделай отчёт за сегодня».

Готовых QA-скиллов под мой стек на find-skills не нашлось, поэтому я собрал свои: 10 скиллов для Claude Code — от критериев приёмки и деплоя до логов, баг-репортов, тест-кейсов в Allure и отчёта. Каждую ошибку агента я превращаю в правило внутри скилла. В статье рассказал, как устроен этот QA-конвейер, где агенту нужны мои апрувы, и опубликовал скиллы в открытый репозиторий.

В последнее время вокруг систем ИИ, генерирующих тесты, активно развивается дискуссия, причем как в профессиональной, так и в академической среде. С одной стороны, такие системы делают ровно то, для чего задуманы ИИ-агенты: выполняют работу, которую мало кто любит делать, экономят массу времени и сил. С другой — порой выдают непредсказуемый результат: удаляют или корректируют тест-кейсы, игнорируют пограничные сценарии.

Мы решили посмотреть, какие мнения есть относительно генеративных тестов в ИТ-индустрии, и что говорит на их счет наука — разобрали свежие исследования по теме. А в конце статьи сделали подборку из открытых инструментов, которые помогут оценить возможности пары «нейросеть + юнит-тесты» самостоятельно.

Вступление.

Хабр, привет! Я Сергей Трофимов, старший инженер по автоматизированному тестированию в «Юзтех». В этой статье мы не будем говорить о том, как правильно и неправильно тестировать, на эту тему уже написано множество шпаргалок, инфографик, статей и книг, да и промышленных стандартов «правильной» разработки существует, наверное, с 10 тысяч. Вместо этого мы разберёмся, одно ли и то же – тестирование до релиза и после него. Точнее: должен ли корабль идти изначально намеченным курсом, или всё же стоит менять направление? И как научиться вовремя привносить полезное и отказываться от уже ненужного – пусть даже когда-то хорошо работавшего. Ответы на эти вопросы мы и попробуем найти.

Часть 1. Начало

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

Так получилось, что я стал первым QA-инженером на новом проекте. В моем случае, речь идет не о стартапе, голого поля не было. В случае стартапа работы порой куда больше, особенно, если вам доверено право выбора инструментов.  В моем случае, бизнес давно существует, идея сервиса долго назревала в недрах домена и вот пришло время собрать команду и начать разработку.  Из вводных понятно, что уже есть рабочая инфраструктура и требования, нет только одного – кода, который можно протестировать.  Итак, на календаре первый рабочий день.

Что будет, если production smoke-тесты начнут вести себя почти как настоящие пользователи? В статье рассказываю, зачем я запускаю автоматические проверки прямо в проде, как они проверяют реальные пользовательские сценарии и почему однажды из-за них статистика мессенджера внезапно оказалась слишком оптимистичной. Разберём synthetic traffic, soft delete, искажённые DAU/WAU/MAU и то, как отделять техническую активность от реальной, не отказываясь от production smoke.

Личная история о том, как я выстраивала автоматизацию с нуля в банковском проекте.

Точка старта: огромный проект, ручной регресс на 5 дней, QA вечно «в мыле».

Через год: автоматизирована половина тест‑кейсов, регресс занимает 2 дня, ручные QA выдохнули и пишут первые автотесты

Ошибка линтера стоит пяти минут. Ошибка сканера, который проверяет сайты на соответствие 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.