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

Привет, Хабр. Меня зовут Егор, я QA Fullstack Java в SENSE на проекте российского банка.

Год назад я был уверен, что ИИ-агент в QA — это либо маркетинг, либо повод искать новую профессию. Сегодня он у меня в проекте разбирает упавшие тесты, актуализирует локаторы и пишет шаблонные кейсы по спецификациям. Расскажу, как мы прошли путь от «он не справляется с добавлением поля в класс» до 1600 рабочих тестов за сутки на хакатоне. А еще расскажу, что в итоге агент так и не научился делать.

Есть устойчивое поверье: интеграционные тесты медленные, потому что ходят в настоящую базу. «Подними SQLite в памяти», «замокай репозитории», «не гоняй Postgres в CI» — стандартный набор советов. Мокать я не люблю, но крыть упрёк «настоящая база — это медленно» было нечем. Поэтому я сел, спрофилировал и померил: 3316 интеграционных тестов, прогон 30 минут. После трёх правок инфраструктуры — 109 секунд. База оказалась ни при чём, а совет «чисти базу через TRUNCATE, это быстрее DELETE» у меня работал ровно наоборот — обидно вдвойне, потому что эта рекомендация уже лежала в черновике моей следующей статьи.

Когда эксперт впервые увидел, как моя машина ведёт себя в динамике, он сказал, что без курсов по двигателям и трансмиссиям меня к такому тренажёру подпускать нельзя. Он был прав. Меня позвали перенести с Unity на Unigine тренажёр гусеничной машины. К середине проекта я решил, что новую физику проще написать с нуля, и не написал в ней ни строки руками — весь код делал Claude Code. И да, там будет Патрик Суэйзи.

В крупных компаниях зоопарк фреймворков автоматизации убивает эффективность. Мы создали централизованное решение на базе Perfeccionista‑framework, подключили к нему RAG и MCP‑сервер для работы с LLM, и теперь языковые модели понимают контекст наших тестов. Главный вывод: будущий QA‑инженер — это промпт‑инженер с глубокими предметными знаниями

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

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

Исследователи Anthropic собрали LLM-агента, который читает код Python-библиотек, сам формулирует свойства, пишет property-based тесты на Hypothesis и ищет контрпримеры. В результате он нашёл баги в NumPy, aws-lambda-powertools, tokenizers и других проектах — часть патчей уже приняли мейнтейнеры. Разбираемся, как работает такой агент, почему property-based тестирование хорошо подходит для LLM и где у подхода пока границы.

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

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

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

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

Каждый раз, когда техно-энтузиасты на Хабре начинают петь оды ИИ, который вот-вот заменит всех разработчиков, меня охватывает легкий скепсис. Дело в том, что многие простые задачи совсем не так просты, как кажутся нейросетям или продакту. Знаменитое: “да что там делать, вон ИИ отдай, к вечеру уже на прод зальете”, обычно открывает такую кроличью нору, что проваливаться и падать там можно неделями, а приземление оказывается очень болезненным. 

Вот казалось бы, что сложного, сделать дверь в игре? В 2014 году у Liz England вышло отличное эссе “Проблема Двери”, где Лиза описывает 22 логических вопроса, на которые должен ответить гейм-дизайнер при установке двери в игре. Эссе стало настолько классическим, что в сабредите r/GameDesign автомод прикрепляет ссылку на него в каждый тред. При этом эссе явно выходит за границы геймдева и становится универсальным, показывая, что кажущаяся простота в нашем деле часто не является таковой. Это касается и дверей в игре, и “просто логина на сайте”, и задачи вызова лифта, и визуализации прогресса ожидания и ещё тысячи вещей, необходимость детального продумывания которых менеджментом обычно в расчет не берется.

Привет, Хабр! Меня зовут Алена Метенева, я руководитель направления по тестированию в Росгосстрахе. А это третья статья цикла про внедрение ИИ в тестирование.

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

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

Про типы границ я впервые услышала на тренинге Алексея Баранцева. Зачем они нужны? Да просто чтобы не забыть всё проверить. Написал чек-лист, потом проверяешь себя:

— Все учел? Вот эти классы эквивалентности, какие границы логические? А какие технологические? ...

Так можно вспомнить о проверке, про которую забыл или просто не подумал! Полезная штука.

Алексей дал нам тогда про такую типизацию границ:

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

В данной статье, мне бы хотелось рассмотреть конкретные полезные инструменты для автоматизации роли QA с помощью AI. Статья ориентирована преимущественно на специалистов уровня junior/middle, а так же - на тех, кому интересно разобраться в современных AI инструментах для профессии QA

Ниже — конкретные шаблоны промптов и список инструментов. Я не претендую на экспертизу именно в QA, но более 17+ лет проработав в TechHR, из которых 12 лет - в AI рекрутинге, включая и найм QA, я вижу, что опыт и знания в области AI - необходим.

Лучшие инструменты для QA в 2026 году

Всем привет! Меня зовут Костя, я QA-инженер в Банки.ру. Недавно мы вчетвером с QA-командой нашли способ оптимизировать нашу работу и сэкономить время на написание тест-кейсов и чек-листов с помощью автоматизирующего рутину бота. На всю разработку у нас ушло около двух недель, а в продакшене бот живёт с апреля 2026 года. Расскажу, как мы это сделали и какие результаты получили в итоге.

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

Тестирование функциональности Direct I/O — задача сама по себе нетривиальная. Сложность возрастает, если проверить работу функциональности можно только на ненагруженной базе данных, а тестируемое приложение предназначено для работы с высоконагруженными системами.

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

Меня зовут Наталья Лабчук, я занимаюсь тестированием Platform V CopyWala — системы резервного копирования и восстановления данных от СберТеха. Расскажу, как мы убедились в том, что функциональность Direct I/O в CopyWala при снятии резервной копии с высоконагруженной базы не ухудшает производительность кластера. Надеюсь, что почитать об этой задаче будет полезно тем, кто работает в разработке и тестировании Postgres-подобных баз данных, а также инженерам, которые отслеживают производительность и администрируют PostgreSQL.

Поднял за выходные продукт, который давно хотел проверить руками: RAG, который отвечает строго по корпусу и к каждому утверждению ставит ссылку на пункт правил — или честно пишет «В корпусе нет основания для ответа». Модель — Gemma-4, локально, через Ollama. Инференс без внешних вызовов: можно физически отрезать сеть — оно продолжает работать.

testing в Go даёт только примитивы. Разбираем, почему автотесты в Go быстро превращаются в боль, и какого слоя исполнения в нём не хватает.

Делюсь опытом. Как я настроил AnythingLLM для небольшой компании на базе VPS и своего домашнего компа. Заказчик хочет оценить все эти ваши GPT на практике, но не готов вкладываться и запрещает отдавать свои тайны публичным языковым моделям. Есть запрос - есть и предложение. Делаем решение из того, что уже есть: VPS на Ubuntu, домашний игровой комп, Mikrotik в качестве роутера. Один вечер и минимум вложений. Заказчик в восторге, я в плюсе!

Полгода назад я написал статью про FlakyDetector — инструмент, который ищет нестабильные тесты по одному лишь исходному коду, Потом была статья FlakyDetector 2.0 . AST + CatBoost, 37 признаков, вроде бы всё круто.

Но один комментарий меня добил.

Пользователь Ariless рассказал реальный кейс: в их проекте тест падал с SLOT_OVERLAP — не потому, что в коде теста было что-то плохое, а потому что фикстура была общая на несколько тестов (shared scope). Предыдущий тест не успел почистить слот — следующий упал.

Привет, Хабр! Меня зовут Станислав Кулагин, я ведущий инженер отдела сертификационного тестирования компании YADRO. Я разработал ATS Studio — Flask-приложение, которое позволяло запускать автотесты в TestY TMS из браузера, не проставляя статусы руками. За полгода приложение стало популярным в нашей компании теперь экономит по 40 часов в месяц коллегам из KVADRA. 

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

Недавно мне поступила задача: провести внешний black-box пентест клиентской панели управления. Входных данных — минимум: только URL. Ни IP-диапазонов, ни схемы сети, ни описания архитектуры.

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

Последние годы развитие LLM шло по пути экстенсивного масштабирования: считалось, что чем больше весов и данных, тем умнее модель. В индустрии даже сложилась жесткая классификация по количеству параметров: 7B, 8B, 32B. Она же создает иллюзию, что модели одной весовой категории обладают сопоставимыми аналитическими, генеративными и логическими характеристиками, что в корне противоречит современным эмпирическим наблюдениям.

Но действительно ли «вес» модели все еще определяет ее качество в 2026 году? Или компактная архитектура способна конкурировать с гигантами, требующими H100 и сотни гигабайт VRAM? В этой статье мы не будем рассуждать об этом абстрактно: возьмем реальные модели из каталога FMC и посмотрим на практике, как размер влияет на качество reasoning, генерации и прикладную эффективность — и влияет ли вообще.