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

Последние месяцы я рецензирую научный софт для JOSS, Journal of Open Source Software. Это настоящий рецензируемый журнал с редколлегией, только статья в нём короткая, около тысячи слов, а главный объект ревью - репозиторий с кодом. Ревью идёт в публичном GitHub-треде под именем рецензента, и весь процесс от заявки до вердикта открыт любому желающему. Я инженер, не учёный: ни PhD, ни публикационного списка у меня нет.

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

Эта статья о том, как встроить регрессию в Scrum так, чтобы она работала весь спринт. Разберём анализ влияния до разработки, наборы проверок P0-P3, тестовую пирамиду, flaky tests, тестовые данные, проверки после релиза и решение о выпуске с понятным остаточным риском.

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

Для проверки я использую четыре типа контролеров: от полностью автоматических O3, где результат можно проверить механически, до O0, где остается человеческое решение. При этом наличие проверки само по себе ничего не гарантирует - важна ее реальная сила: охват, надежность, устойчивость и независимость. Эту модель я называю градиентом автономности.

Теперь попробуем применить ее к данным и аналитике

Как перейти от разовых ИИ-запросов к многоразовым Agentic AI рабочим процессам в QA. Я собрал несколько практических примеров, паттернов и предостережений, которые помогут инженерам по тестированию осуществить этот переход постепенно

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

Разберём, как тестировать такие ситуации через последовательные и параллельные запросы, какие ответы считать корректными и почему одного успешного HTTP‑ответа недостаточно, чтобы подтвердить безопасность изменений.

Четыре фамилии, четыре специальности, четыре кабинета. Сколько разных врачей окажется в журнале на две тысячи строк? Шестьдесят четыре.

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

Третья часть цикла про TDCV2 — открытый конструктор тестовых данных, который я пишу сам. Про то, что делать, когда несколько колонок описывают один и тот же объект и обязаны меняться только вместе.

Школьный класс принято считать моделью общества. На деле это случайный набор людей одного года рождения, живущих в одном микрорайоне, и больше их не объединяет ничего — во взрослой жизни вы никогда не окажетесь в такой группе. Плюс из класса нельзя выйти. Разбираю главный аргумент против семейного обучения по 578 комментариям к первой статье: что такое социализация по определению, чего боятся спорящие и что об этом говорят исследования.

Стенд работает, а исходников программы ПЛК нет — ни архива, ни резервной копии, ни у эксплуатанта. Есть 4 900 страниц бумаги: распечатка проекта, экспорт экранов, руководство по эксплуатации, сканы схем. Задача — восстановить поведение один в один. Эталоном я сделал руководство, а не распечатку кода, и на этом нашёлся таймер, который держал максимальный ток 5 минут вместо разрешённых 10 секунд. Ниже — как читаются пять тысяч страниц, как выглядит data-driven программа ПЛК (с кусками настоящих файлов) и все 7 расхождений с честной пометкой, чем каждое найдено.

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

Первый раз это сработало ровно так, как я мечтал. Агент сказал «у меня нет такого навыка», спросил разрешения, минуту пыхтел компилятором и отчитался: готово.

Метода не было. То есть он был — в манифесте, в списке, который скилл про себя рассказывает. А в коде, который этот вызов должен обрабатывать, его не было. Модель объявила метод, забыла реализовать и об этом не узнала. Валидация прошла. Установка прошла.

Проблема оказалась не в том, что модель ошиблась — это скучно и ожидаемо. Проблема в том, что я не смог поймать ошибку, потому что спрашивал у того же, кто её сделал. Скилл заявляет о себе сам, проверить заявление можно только у него же, а он в этом вопросе — заинтересованная сторона.

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

Привет! В этой статье я разберу, почему возможностей Chiseltest может не хватать для сложного аппаратного тестирования и как мы пришли к собственному фреймворку на базе Verilator и C++. Поговорим об архитектуре тестового окружения, BFM-агентах, автогенерации обвязки и интеграции с RTL и программными моделями. А заодно обсудим, какие задачи с таким подходом решаются лучше, чем с Chisel, и где все-таки остаются ограничения.

Привет, Хабр! Меня зовут Никита Хробостов, я QA-инженер в Just AI. Тестирую диалоговые системы: чат-ботов и голосовых ботов, часть из них с обращениями в RAG.

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

Чтобы было понятно про объемы. На проекте голосового бота у нас 13 активных сценариев, на чат-боте один. Чтобы проверить один сценарий целиком, нужно от 40 до сотни с лишним звонков, а тест-кейсов при этом в два-четыре раза больше: зависит от дизайна. На полную проверку одного небольшого сценария уходит 5–6 часов.

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

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

Полгода назад в нашем продукте был один автотест. Сейчас их 878, и заметная часть написана командой ИИ-агентов. Рассказываю, как устроен харнесс из специализированных ролей, почему новый инструмент не попадает в него без RED/GREEN-доказательства пользы, и почему в системе, где код пишут агенты, самой дефицитной компетенцией оказывается тестирование.

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

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

Свой язык программирования пишут все. Обычно это калькулятор с переменными, пересказ главы про рекурсивный спуск и заброшенный репозиторий.

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

Не сломал. Полная перестройка ядра — 350 строк — прошла все 444 проверки, и ни один эталон не пришлось трогать.

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

Плюс двенадцать дефектов, которые нашёл фаззер: равенство, переставшее быть симметричным; undefined, вылезающий наружу в языке, где его нет; += , вычислявший цель дважды. Два из двенадцати нашёл не фаззер, а я — когда писал тесты к его находкам.

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

У виджета было 92 теста и 100% построчного покрытия. Потом я открыл его в маленьком окне терминала, и шапка таблицы уехала за верхнюю границу экрана.

Разбор трёх багов, которые нашлись при разработке пакета поверх экспериментального компонента symfony/tui: одного своего, который не поймало полное покрытие, и двух чужих — их исправления смержены в ядро Symfony. Плюс третий, найденный уже после того, как его починили без меня, — таб в ячейке ломал выравнивание всей таблицы.

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

В 2024 году исследователи провели простой эксперимент: взяли тесты с вариантами ответа и начали менять варианты местами. Сами вопросы и содержание ответов оставались прежними.Казалось бы, какая разница, находится правильный вариант под буквой A или под буквой C?

Оказалось, разница есть. В работе Large Language Models Sensitivity to The Order of Options in Multiple‑Choice Questions авторы показали заметный разброс качества моделей при перестановке вариантов. На разных сочетаниях моделей и датасетов разрыв оказался очень большим.Уже неприятно. Но дальше становится интереснее.

Ответы LLM часто оценивают с помощью другой LLM. Такой подход называют LLM‑as‑a‑Judge: модель получает вопрос, эталон или критерии, ответ тестируемой системы и выставляет оценку. Однако и такой судья не идеально объективен. В исследовании Judging LLM‑as‑a‑Judge with MT‑Bench and Chatbot Arena описаны, в частности, позиционное смещение и предпочтение более подробных ответов.

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

Что происходит, если вместо массовой раздачи AI-инструментов сначала изучить, как на самом деле работают команды?

Рассказываю, как мы начали AI Enablement в крупной финансовой организации: оценили 13 команд, визуализировали их delivery pipelines, обучили около 800 человек и построили программу вокруг реальных ботлнеков, а не вокруг модных AI-инструментов.

Где команда получила ускорение почти в 9 раз, почему на другом сценарии выиграла всего 11 часов и зачем считать настройку агента частью тестирования

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

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

Привет, Хабр! Меня зовут Анатолий Овчинников, я бизнес-архитектор и владелец продукта Goodt Insight (ИТ-холдинг LANSOFT). Отвечаю за архитектуру продуктов, которые живут в проде годами и переживают не один состав команды. ИИ мы используем каждый день — поэтому его эффекты я вижу не на демо, а на дистанции в месяцы, когда к коду возвращаются.