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

Делюсь личным опытом создания проекта с нуля на вайбкоде.

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

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

Я заметил, что стал копипастером задач в ИИ-агента и обратно, а из программиста превратился в GUI-тестера. Не самая моя любимая работа.

Сначала наваял простой скрипт на Python: сделать скриншот, ткнуть мышью в координаты. В итоге тихим сапом это выросло в круглосуточный конвейер, который ведёт задачу от тикета в YouTrack и общения с пользователем до доказательства в живом 2D/3D-интерфейсе и коммита. И ещё писатель документации со скриншотами в придачу.

Рассказываю, как оно росло, какие были грабли и сколько строк в итоге занял наследник того самого «простейшего скрипта».

Первое нагрузочное тестирование часто начинается с формулировки «давайте запустим побольше пользователей и посмотрим».

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

Привет, Хабр! Меня зовут Михаил Рязанский, я руководитель группы технической аналитики в Дзене. Группа включает в себя команды DWH, антифрода, аналитики модерации и ML‑аналитики. Вместе с Марком Хабаровым, лидом команды ML‑аналитики, мы расскажем про наш инструмент для анализа результатов А/Б‑тестов и про интеграцию в него LLM. Получилось интересно, местами — больно. Но обо всём по порядку. 

Казалось бы, учетная запись в GitLab — не самая удачная стартовая точка для инфраструктурного пентеста. Ни VPN в корпоративную сеть, ни доменного аккаунта, ни даже RDP на рабочую станцию, только креды рядового разработчика. Вряд ли в начале проекта заказчик ожидал серьезного импакта, но мы доказали, что при типовых настройках CI/CD такая учетка находится на расстоянии нескольких прыжков до контроля над облаком. 

Давайте вместе пройдем эту цепочку.

С февраля у меня на ноутбуке крутится автономный агент Сурок: Claude Code, флаг --dangerously-skip-permissions и ральф-луп поверх. Работает — сидишь, кофе пьешь, смотришь, как горят токены. Потом я прогнал Сурка и еще пять своих проектов через свод инженерных практик, и у идиллии появилось имя: «Level 5 автономии при Level 1 границах». Внутри — диагностика из десяти вопросов, чужой боевой опенсорс на десятки тысяч звезд и методология PDLC Сбера, где эти грабли уже каталогизированы.

27 июля Moonshot AI открыла веса Kimi K3 и опубликовала результаты модели на coding- и агентных бенчмарках. Мы проверили, как эти показатели переносятся на рабочие операции с файлами, счетами, корзинами, платежами, возвратами и отчётами.

Kimi K3 прошла 204 задачи PAC1 и ECOM1 и набрала 61/104 и 44,75/100. В статье разбираются публичные трассы успешных задач и повторяющиеся отказы: нарушение точной схемы, частично выполненные транзакции, ошибки в длинных таблицах, неоптимальные маршруты и пропущенные проверки доверия. Все запуски и трассы доступны для проверки.

Сорок клиентских сайтов. У каждого четыре проверки: доступность, сертификат, срок домена, битые ссылки. Сто шестьдесят проверок, заведённых руками через веб-интерфейс.

Пока их двадцать, это терпимо. Когда приходит сорок первый клиент, ты открываешь кабинет и снова кликаешь: создать проверку, интервал, порог, теги, сохранить. Четыре раза. А потом кто-то спрашивает: «а почему у этого сайта порог два, а у соседнего три?» — и честный ответ звучит как «не помню».

Инфраструктуру мы описываем кодом уже лет десять. Мониторинг — почему-то нет. Хотя это ровно такая же конфигурация: её надо ревьюить, версионировать и уметь воспроизвести.

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

Курс «HighLoad тестирование для 1С и корпоративных систем: полный курс» посвящен всему циклу нагрузочного тестирования: от анализа исходной системы и проектирования сценария до запуска тестов, интерпретации результатов и подготовки рекомендаций...

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

Привет, Хабр! Меня зовут Ольга Ришко, старший специалист по тестированию медицинской информационной системы (МИС) «БАРС Груп». В этой статье я расскажу, почему медицинское ПО нельзя проверять как набор отдельных экранов и API‑методов, откуда берутся «успешные» операции с неверным результатом, что именно ручной тестировщик ищет между интерфейсом, базой данных (БД), фоновыми задачами и интеграциями, где рождаются самые неприятные дефекты и почему ручное тестирование в медицинских технологиях по‑прежнему остается не запасным вариантом, а важной частью контроля качества.

21 июля я сидел, обновлял ленту и ждал Gemini 3.5 Pro – тот самый флагман, который Google пообещала ещё в мае на I/O. «В следующем месяце», – сказали они тогда. Прошло два. Я уже мысленно прикрутил этот релиз к списку «когда-нибудь», но вместо флагмана компания выкатила… три модели тира Flash. Ни одной Pro. Знакомо, да?

И вот что интересно: в руки попали не просто затычки, а модели, которые для 90% реальной работы полезнее ещё одной строчки в таблице интеллектов. Особенно когда выяснилось, что экономия в 17% выходных токенов на самом деле тянет за собой цепочку издержек и способна сделать агентную разработку дешевле почти вдвое. А ещё новая версия местами просела в чтении графиков – и об этом молчат почти все.

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

Правило из CLAUDE.md агент забывает на длинной сессии - это текст, а не механизм. Я разобрал слои дисциплины Claude Code и прибил критичные правила хуками: три гейта, после которых коммит без свежего зеленого прогона тестов не проходит, правка теста поднимает флаг, а завершить работу с грязными тестами нельзя. Под катом механика хуков, код всех трех гейтов с живыми прогонами и эксперимент, где гейт пересилил прямую инструкцию пользователя.

Как перестать доверять LLM-судье на слово и построить безопасную двухконтурную систему оценки?

Внутри статьи:

Архитектурный паттерн сдерживания: почему у классической нормализации должно быть право вето.

CI-инварианты: как ловить галлюцинации моделей с помощью враждебных фикстур в grounded-judge-gate.

Разбор факапов: три реальных бага проектирования, которые едва не увели систему в ложноположительное пике.

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

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

При этом цель осталась прежней – сократить время QA на анализ требований. Раньше приходилось руками собирать всё по ссылкам, искать недостающую информацию, проверять версии файлов, находить таблицы с калькуляциями, файлы с эмуляторами и иногда просто выяснять, какой документ сейчас считается актуальным. Поэтому мы пошли на уровень раньше и начали отдельно собирать корпус требований в Codex (но это уже следующая статья). А в данном материале покажу общий подход и несколько правил из промптов, возможно кому-то они пригодятся.

Автотесты писали, чтобы экономить время. Но в какой-то момент поняли, что тратим на их обслуживание больше, чем экономим. 

Тест упал в CI — открываешь Allure, идёшь на стенд через VPN, авторизуешься, лезешь в DOM, ищешь, какой локатор отвалился. Полчаса-час на один тест. Прошёл релиз, и ещё пара дней уходит на то, чтобы починить локаторы после того, как фронтенд поменял вёрстку. А когда с утра видишь 200 красных тестов при нетронутом коде, начинается расследование. 

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

Всем привет! На связи Егор Лаптев — QA Fullstack Java в SENSE на проекте крупного российского банка.

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

В примерах стек Selenide, Cucumber, REST Assured, Allure, Kafka и Moon в Kubernetes, но сами принципы переносятся на любую связку UI- и API-тестов.

Запустить ИИ-агента на багбаунти — дело пяти минут. Зато превратить его поток сознания в принятые отчеты, чтобы не словить бан за спам и минус в рейтинге, — задача со звездочкой.

Привет, Хабр! Меня зовут Владислав, я работаю в отделе реагирования на инциденты в Бастионе и около полутора лет активно ханчу на багбаунти. Под Новый год мы с другом так пробили ИБ-интегратора (он, кстати, остался доволен), а недавно я выиграл Bug Zone 7.0. Подобные активности — хорошая возможность поэкспериментировать и выработать новые подходы, и последние полгода я ищу баги при помощи LLM. Так что с ИИ можно добиваться хороших результатов, а не сдавать мусор. Но как это делать? 

Под катом вас ждут: 

• четыре подхода к ИИ-багхантингу; 

• четыре способа платить за модель; 

• три слоя верификации;

• пайплайн из двух агентов; 

• живой разбор blind SSRF. 

Спойлер: готовой кнопки «сделать хорошо» не ждите. 

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

Привет, Хабр! Мы — команда разработки кредитных продуктов для физических лиц в Т-Банке. Делимся опытом нагрузочного тестирования workflow-движка Zeebe (основы Camunda 8), который проводили, когда искали альтернативу Camunda 7.

Вокруг Zeebe ходит немало стереотипов: медленный, сложный в настройке, нестабильный. Но большинство мнений основаны на данных, актуальных для устаревших версий. Мы приняли во внимание развитие продукта и провели собственное исследование.

В секциях по интеграциям, DevOps и тестированию пока меньше заявок, чем в других направлениях INFOSTART TECH EVENT 2026. Это повышает шансы сильной темы пройти отбор, попасть в голосование и войти в программу конференции.

Приём заявок на INFOSTART TECH EVENT 2026 продолжается. Сейчас особенно ждём доклады в три секции:

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