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

Нейросети скоро полностью заменят человека в IT! Вакансий для «кожаных мешков» уже почти не осталось! Гипс снимают! Клиент уезжает! Эти тезисы за последний год успели превратиться в универсальное объяснение происходящего в околокомпьютерной сфере. Нейросети пишут код, находят ошибки, генерируют документацию и даже проектируют архитектуру приложений. Казалось бы, до полной автоматизации разработки осталось совсем чуть-чуть. А что насчет тестирования? Неужели и здесь человек скоро окажется лишним?

Привет, Хабр! Меня зовут Дима Борщевский, я QA Engineer в Авито Товары и работаю в IT около десяти лет. В последнее время я разбираюсь, какую часть подготовки мобильных E2E-тестов можно передать ИИ-агенту без снижения требований к качеству.

Сгенерировать несколько строк на Kotlin или Swift несложно. Сложнее получить изменение, которое использует инфраструктуру конкретного проекта, подготавливает воспроизводимые данные, проверяет результат каждого действия, компилируется и запускается. Обычного запроса в духе «напиши E2E-тест оформления заказа» для этого недостаточно.

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

Привет, Хабр! Я Александр Молодцов, старший специалист по тестированию в ГК «Юзтех».
В самом начале хотелось бы выделить одну важную мысль: ситуация, разобранная в статье, не является хрестоматийной – примеры решения проблем, которые в ней затронуты, являются лишь частными примерами, не более того.  Все имена вымышлены и совпадения случайны. 

Исследование поведения ИИ-агентов с вызовом функций, имеющих реальный эффект, проводилось на основании методологии, основные положения которой мы излагали ранее (https://doi.org/10.5281/zenodo.23556771,https://habr.com/ru/articles/1098088/). Прогоны проведены по методологии версии 3.1; тестовая система этой версии не публиковалась.

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

Тестирование в этой версии проходило в два этапа и завершалось подтверждающей проверкой:

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

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

Инфостарт Обучение опубликовал расписание пяти курсов со стартами с января по май 2027 года. До 31 декабря 2026 года участие можно оформить и оплатить по текущей стоимости: с 1 января цены на эти программы вырастут. В подборке - управление ИТ-проектами, разработка отчётов, DevOps, нагрузочное и автоматизированное тестирование.

Привет, Хабр! Меня зовут Евгения Мясникова, я QA-инженер SpaceWeb. Передавать искусственному интеллекту рутинные задачи тестирования — подготовку черновиков тест-кейсов, первичное покрытие, оценку трудозатрат и другие — уже стало привычной практикой. Однако при таком разнообразии инструментов важно понять, как эффективно встроить ИИ-агентов в рабочие процессы и распределить задачи между специалистом и нейросетью.

В этой статье расскажу, как мы совместно с руководителем отдела исследований и разработки SpaceWeb Виталием Киреевым разработали первоначальную модель взаимодействия QA-специалиста с LLM. Для работы с чувствительными данными мы интегрировали агента с локальной моделью Qwen3.8-27B. На реальных примерах покажу, в каких задачах ИИ действительно нам помог, а где его применение пока вызывает вопросы.

14 октября в логах нашего API нашлась строка «relation “message_watchdog” does not exist». Таблицы сторожа потерянных сообщений не было ни на dev, ни на проде, хотя код, который в неё пишет, жил в репозитории с апреля и на каждый вызов отвечал success: true. Рассказываю, как переименование миграции в V10b спрятало её от Flyway и почему мой мониторинг полгода докладывал, что всё спокойно.

Я хотел автоматизировать работу с GitHub через локального ИИ‑агента, в итоге пришлось написать PowerShell‑конвейер для создания Pull Request. В какой‑то момент стало интересно: выдержит ли GitHub больше тысячи автоматически создаваемых PR с обязательным CI и Auto Merge.

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

Привет, Хабр! Поехали!

Spec-Driven Development (SDD) за год стал главным словом в разработке с агентами: AWS выпустил Kiro, GitHub — Spec Kit, появились OpenSpec и Tessl, доклады про SDD идут на каждой конференции. Идея простая → перед тем как агент пишет код, человек пишет спецификацию, и агент работает по ней, а не по чату из десяти сообщений. Озвучу интересный тезис → SDD в его нынешнем виде — это очередная инкарнация водопада, только артефакты теперь в markdown, а исполнитель — LLM. Разберу, почему все туда идут, что в SDD работает, где он ломается и какие есть альтернативы.

Откуда хайп: старая теория под новую практику

Любая новация в отрасль приходит по одному сценарию. Сначала появляется успешная практика → ИИ-copilot у разработчика, вайбкодинг у бизнеса. Практика работает, но её никто не понимает, и под неё достают старую теорию. Для агентной разработки такой теорией стал SDD: «сначала спецификация, потом код» — это ровно то, чему учили в 90-е. Теория работает плохо, и сквозь неё прорастает уже другая практика. Мы сейчас на второй стадии.

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

В апреле здесь вышла статья «Кризис инструментария API». Автор перечислил всё, за что разработчики не любят Postman и его наследников, и закончил мыслью, что лучший инструмент, наверно, ещё не создан. Может быть, его напишете вы.

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

Делал я его для себя, под свою ежедневную работу, и да, я еще пользуюсь API‑клиентами в эпоху харнессов. Поэтому в нём нет того, ради чего обычно хотелось уйти или удалить приложение: аккаунта, облачных воркспейсов, тарифной сетки, телеметрии на каждый шаг. Каждая функция появилась потому, что мне или друзьям её не хватало, а не чтобы добавить строчку в таблицу сравнения. Идея статьи такова: инструмент получился, им пользуемся не только мы, и хочется, чтобы о нём узнало больше людей. Может быть, кому‑то он подойдёт так же, как подошёл мне.

Ниже расскажу, как он устроен, где выигрывает у Postman, Insomnia и Bruno, а где пока проигрывает. Отдельный раздел — для тестировщиков: тесты, прогон коллекций по CSV, моки и нагрузочные тесты на k6, и всё это можно запускать в CI. В конце — про версию 3.0, которая вышла 7 ноября.

OpenRewrite обновил зависимости, поправил код, тесты прошли — кажется, миграцию на Spring Boot 4 можно считать успешной. Но что, если после такого обновления старые клиенты начнут получать 400, а привычные значения в JSON внезапно изменятся? На примере сервиса заказов разберём, откуда берутся эти расхождения и как поймать их до выката с помощью снимков API‑контракта.

Пост стал новостью, новость — статьей, а тестирование железа все еще остается тестированием железа. Или и здесь не все так просто?

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

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

После урока по SQL хочется где-нибудь порешать задачи. Ставить ради этого базу и придумывать себе данные бывает лень, особенно когда ещё путаешься в JOIN.

Собрал шесть тренажёров, к которым можно перейти сразу после теории. Есть обычный задачник, несколько игр и мой бот в Telegram. Пишу с уклоном в QA: я работаю QA-лидом и обучаю тестированию, поэтому смотрю в первую очередь на то, какие задания можно использовать при подготовке.

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

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

Мы в команде Checks (Antifraud) собрали такой сетап — af-checks-context. Сейчас мы раскатываем его с моего личного использования на всю команду, чтобы быстро шарить контекст и автоматизировать процессные договорённости. Расскажу, на чём мы обожглись и почему в какой-то момент его пришлось почистить.

В американском штате Нью‑Йорк запустят первую в США государственную программу независимого тестирования систем искусственного интеллекта и подготовки нового поколения экспертов безопасности в области нейросетей. Об этом сообщила губернатор штата Кэти Хокул.

Всем привет! Меня зовут Костя, я QA-инженер в Банки.ру. 12 октября наш проект в Allure TestOps (это TMS, система управления тестированием) с 1539 тест-кейсами стал недоступен, и штатно восстановить его не получилось. К 14 октября мы собрали его заново. Помогли JSON-выгрузка от 2 октября и вики в Obsidian, где записано устройство проекта.

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

Мы решили в интересном формате рассказать о важном направлении для Контура — тестировании ⭐️ и сравнить то, как мы воспринимаем себя, с тем, что думает о нас рынок.

Привет, Хабр! На нашем ИТ-митапе для технического комьюнити эксперт ГК «КОРУС Консалтинг» выступила с темой «Автоматизация тестирования с помощью ИИ: идеи, гипотезы, результаты».

У нас было 15 000 ₽ в месяц, команда из пяти человек и катастрофическая нехватка времени на ручное тестирование. И мы призвали Духа Машины. 

Мы команда тестирования Главной страницы Яндекса. Как и у любой QA‑команды, у нас гора рутины: открыть задачу; понять, что в PR; накидать чек‑лист; написать тест‑кейсы; автоматизировать; потом чинить, когда тесты падают на CI. Теперь Дух Машины берёт на себя значительную часть этой рутины: читает тикеты и PR, пишет чек‑листы, кейсы и автотесты, чинит упавшие тесты и ревьюит код. Он помогает всем тестировщикам команды. 

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