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

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

Курс «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 области.

Если вы работаете с системами для управления корпоративным контентом, то понимаете, что главная их проблема — это недостаточный уровень производительности. То, что прекрасно работает на 20 документах, тормозит и выдает ошибки на 2 млн. Как узнать об этой проблеме до того, как система сдана клиенту в промышленную эксплуатацию? Ответ: провести нагрузочное тестирование.

Привет! Мы — Владимир Семенов, старший системный архитектор LDM (входит в холдинг LANSOFT), и Олеся Панкова, инженер по нагрузочному тестированию. В нашей статье — не сухие цифры из отчета, а экспертиза инженеров команды.

В июле появились признаки улучшения ситуации по Automation QA и Senior QA - число нанимающих компаний по этим ролям за месяц уменьшилось всего на 0.2%. Это минимальное падение за последние три месяца, и оно в рамках погрешности измерений.

Совершенно другая ситуация с ролью Manual QA - здесь уверенное падение продолжается. Процент нанимающих компаний в очередной раз снизился и достиг 21.6%. Для сравнения: в феврале нанимающих компаний было 40.7%. То есть меньше чем за полгода произошло двукратное падение!
Что интересно, с приходом AI это никак не связано - на американском рынке, где масштабное внедрение AI идет уже давно, в июле число вакансий Manual QA выросло.

По ролям AI QA / ML Evaluation ситуация продолжает оставаться непонятной - некоторый рост есть, но на фоне изначально низкого числа вакансий он очень незначителен.

Представьте, однажды вы приходите в новую компанию на позицию Automation QA и перед вами возникает задача: на пустом поле проекта посеять зерна автотестов, которые прорастут в регулярный процесс тестирования и будут отлавливать различные баги. Такая задача возникла и передо мной, поэтому я хочу поделиться своим опытом, как строил тестирование кастомного K8s CNI-плагина в новой для себя области. Статья будет полезна QA-инженерам, которые на «ты» с Python, но на «вы» с тестированием Kubernetes с помощью автотестов. При решении задачи я столкнулся с вопросами, на которые нигде не нашел ответа. Возможно, раз мне помог описанный путь, поможет и вам.

Origami Framework — фреймворк для автоматизации тестирования на Java, созданный с целью упрощения построения тестовой архитектуры и ускорения процессов приёмочного и регрессионного тестирования

Привет, Хабр! Меня зовут Михаил Косцов, я руководитель практики вычислительной инфраструктуры, СХД и СРК К2Тех. Для нас серверное железо – рабочий инструмент, и мы обязаны знать его возможности. Когда к нам в лабораторию попали два сервера YADRO, мы гоняли их 24 часа под полной нагрузкой, выдергивали диски на ходу и до предела грузили вычислениями.

Под катом – разбор VEGMAN R220 G3 (2U-сервер с парой Xeon Max 9480 и встроенной HBM-памятью) и YADRO G4208P G3 (4U-платформа под ИИ-нагрузки с двумя видеокартами NVIDIA H100 и парой H200). Будут бенчмарки, стресс-тесты, проверка отказоустойчивости и много графиков.

Обычные тесты находят только ожидаемые ошибки. В статье разберём, как Hypothesis сам ищет контрпримеры и сокращает их до минимального сбоя.

Тест кликает с force: true, ждёт waitForTimeout(3000) и не делает ни одной проверки — а CI с подключённым eslint-plugin-playwright зелёный: все три греха в recommended — warning. Я выписал из исходников плагина, где error, а где warn. Под катом — конфиг, который это чинит. Ну и десять правил ревью, до которых линту не дотянуться в принципе.

Можно ли использовать методологию создания интерфейсов "Atomic Design" вместо Page Object? Попробуем разобраться что между ними общего и насколько "Atomic Design" применим в автоматизации тестирования.