Тестирование систем машинного обучения (ML) — сложная и малоосвещённая тема. В отличие от классического ПО, ML-системы работают на основе вероятностных моделей и данных, а не жёстких правил. Это вносит свои особенности и вызывает ряд уникальных трудностей. В этой статье — разбор типичных проблем, подходов к тестированию и реальных кейсов из практики.

Кратко о проекте

Работаем над системой автозаказа для сети супермаркетов Spar. Задача — точно рассчитывать объёмы заказов, чтобы товара хватало, но не было излишков. Система учитывает десятки факторов: сезонность, погоду, праздники, календарные события. Например, перед 1 сентября растёт спрос на цветы — модель это учитывает и корректирует поставки.

Почему тестирование ML сложнее обычного

• Вероятностное поведение вместо детерминизма. В классическом ПО одинаковые входные данные всегда дают одинаковый результат. В ML система выдаёт прогноз с определённой вероятностью. Поэтому тестирование сводится не к проверке точного ответа, а к оценке качества прогноза и допустимых отклонений.
• Фокус смещается с кода на данные. Даже самая продвинутая модель даст плохой результат на некачественных данных. Проверка датасетов — критически важная часть тестирования.
• Устаревание модели (model drift). Модель обучается на прошлых данных, но реальность меняется. Появляются новые товары, меняются привычки покупателей. Если не мониторить и не дообучать модель, её точность будет падать.
• Контекст и цена ошибки. Ошибка в 10% для жевательной резинки — не критично. Та же ошибка для дорогого товара — может обернуться серьёзными убытками. Тестирование должно учитывать бизнес-последствия.
• Новые типы ошибок. Появляются проблемы с данными: аномалии, сбои в интеграциях, некорректные источники. Такие ошибки сложнее обнаружить, чем баги в логике кода.

Тестирование ML на этапах разработки

Анализ требований

В классическом тестировании требования чёткие: «сделай X, получи Y». В ML заказчик говорит: «улучшите прогноз». Но как измерить «улучшение»?

Мы вводим метрики:

• Технические — насколько прогноз отличается от факта.
• Бизнес-метрики — влияние отклонения на прибыль и продажи.

Также договариваемся о допустимых отклонениях. Например, прогноз спроса на шоколад может отличаться от реальных продаж не более чем на 10%.

Планирование тестирования

Ожидаемый результат в ML — не конкретное число, а диапазон. Например, прогноз должен попадать в ±10% от факта.

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

Настройка окружения и подготовка данных

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

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

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

Выполнение тестов

Тестирование осложняется отсутствием точного ожидаемого результата. Опираемся на метрики и диапазоны.

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

Тестируем на выборке: наборе разнообразных магазинов. Это быстрее, чем тестировать всё, но даёт представление о качестве.

Помимо модели, проверяем:

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

Регрессия

После обновления модель может улучшить одну метрику, но ухудшить другую. Важно анализировать такие случаи: критично ли падение?

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

ML-тестирование: шеф-повар, а не повар

Тестирование обычного ПО — как следование рецепту: всё расписано, результат предсказуем. Тестировщик проверяет, что всё сделано по инструкции.

ML-тестирование больше похоже на работу шеф-повара: нет точного рецепта, результат может варьироваться, нужно «пробовать на вкус». Тестировщик оценивает качество, предлагает корректировки и решает, готова ли модель к работе.

Преимущества ML-тестирования

• Полноценное A/B-тестирование. Новую модель можно запустить параллельно со старой и сравнить в реальных условиях.
• Реалистичные данные. Тесты проводятся на данных, близких к продакшену, что позволяет выявить проблемы до релиза.
• Контроль через метрики. Ухудшение качества сразу заметно — можно оперативно дообучить модель.
• Больше данных — больше сценариев. Возможность проверить поведение модели в разных условиях.
• Проверка устойчивости. Можно моделировать сезонность, аномалии и изменения спроса, чтобы заранее выявить слабые места.

Реальные факапы

• Грузовик молочки. Из-за путаницы в параметрах prediction_share и predict_share система выдала завышенный прогноз по молочным продуктам. В магазины приехало избыточное количество творога, сметаны и масла. Пришлось распродавать со скидками. Проблему можно было предотвратить, если бы аномалия была замечена на этапе тестирования.
• Недопрогноз лавашей. После обновления модель перестала учитывать выходные пики спроса на лаваш. Продажи небольшие, поэтому проблему заметили поздно. Покупатели приходили за лавашем, а его не было. Кейс показал важность детального тестирования по всем категориям, даже с низким объёмом продаж.
• Модель не узнала 2025 год. Из-за ошибки в кодировке параметра year модель не распознала начало нового года. Прогнозы стали некорректными. Система аномалий тоже не сработала. Пришлось срочно вручную корректировать заказы. Урок: нужно тестировать модель на будущих данных и проверять работу системы обнаружения аномалий.

Привет! Сегодня хочу поделиться опытом тестирования на ML-проекте. По моему опыту, о машинном обучении говорят много, а вот о его тестировании — заметно реже. На истину в последней инстанции не претендую, но надеюсь быть полезным. Если у вас был опыт тестирования ML – буду рад обсудить в комментариях!

На всякий случай напомню: меня зовутМаксим Белопросов, яQA Team Leadв компании1221Systemsи один из ответственных за направлениеавтоматизированного тестирования.

В этой статье я хочу рассказать:

1. кратко о нашем ML-проекте, чтобы погрузить в контекст
2. с какими трудностями мы столкнулись
3. как решали их на практике

P.S. Я пишу с позиции тестировщика, а не ML/DS‑специалиста.

Что такое ML?

На всякий случай кратко напомню:ML(Machine Learning, машинное обучение) — это подход, при котором системаучится на данных, а не по заранее прописанным правилам.

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

Кратко о проекте

Есть такая сеть супермаркетов Spar. Каждый день каждому магазину нужно точно рассчитать объём заказа: товара должно хватить всем покупателям, но при этом нельзя допустить излишков и последующих списаний.

В этом помогает AutoOrderService — система автозаказа. Она анализирует десятки факторов: сезонность, погоду, праздники, календарные события. Например, за несколько дней до 1 сентября система фиксирует рост спроса на цветы и уже 30–31 августа прогнозирует увеличение поставок.

Почему тестирование ML сложнее обычного

1. Детерминизм vs вероятностьВ классических системах результат детерминирован: при одинаковых входных данных мы всегда получаем один и тот же результат. Простой пример — если отпустить яблоко, оно упадёт вниз.ML-системы работают иначе. Их поведение вероятностное: модель не «знает» ответ наверняка, аоценивает вероятность различных вариантов. Это больше похоже на бросок кубика — мы не можем предсказать конкретное число, но можем говорить о вероятностях.Из-за этого в тестировании мы проверяемне конкретный ответ, а качество прогноза и допустимые отклонения.
2. Фокус смещается с кода на данныеВ ML-проектах объект тестирования —не только код, но и данные.Код — это механизм, а данные — топливо.Даже самый продвинутый алгоритм даст слабый результат, если обучался на некачественных и/или неполных данных. Поэтому проверка датасетов становится критически важной частью тестирования.
3. Устаревание модели (model drift)Модель обучается на исторических данных, но реальность меняется.Появляются новые товары, меняются покупательские привычки, случаются кризисы.Если модель не переобучать и не мониторить её качество, точность прогнозов начинает постепенно снижаться. Это называетсяустареванием модели— и это отдельный объект контроля в ML-тестировании.
4. Контекст и цена ошибкиКак мы знаем, протестировать всё невозможно. Поэтому важноуправлять риском и учитывать бизнес-контекст.Например, ошибка прогноза в 10% для дешёвого товара (например, жевательной резинки) почти незаметна. Та же ошибка для дорогой категории может обернуться существенными финансовыми потерями.Тестирование должно учитывать не только метрики модели, но и стоимость ошибки для бизнеса.
5. Новые типы ошибокПомимо классических багов в коде появляются ошибки данных:аномалии,некорректные источники данных,проблемы интеграции,и т. д.Часто такие ошибки сложнее обнаружить, чем обычный дефект в логике программы.

Рассмотрим тестирование ML на каждом этапе разработки ПО

1. Анализ требованийВ классическом тестировании всё относительно просто: аналитики дают нам документацию, мы изучаем её и понимаем, что делает продукт и какие у него ограничения. Наша задача – не только разобраться, но и вовремя заметить ошибки или противоречия в документации. Чем раньше нашли – тем быстрее исправили.С тестированием ML всё сложнее. Например, заказчик говорит: «Нужно улучшить прогноз продаж товаров в магазине». Но как понять, что прогноз стал лучше? Тут нет чёткой инструкции и единственного правильного ответа.Чтобы это оценивать, мы ввели специальные метрики:технические(например, насколько сильно прогноз отличается от факта),бизнес-метрики(насколько это отклонение влияет на продажи и прибыль).Так же мы договариваемся окосвенном ожидаемом результате: например, прогноз спроса на шоколад может отличаться от реальных продаж максимум на 10%. Если больше – значит модель работает некорректно.
2. Планирование тестированияВ классическом тестировании после анализа требований мы пишем тестовую документацию: описываем шаги, условия и ожидаемый результат. Это нужно, чтобы потом сравнить ожидания с фактом.В ML всё иначе — правильного ответа нет. Вместо этого мы задаём допустимые диапазоны. Например, прогноз спроса может отличаться от реальных продаж не больше чем на 10%.Кроме того, на вход могут поступать некорректные, например аномальные, данные. Это такие ситуации, которые не отражают обычный спрос: компания скупила всё мясо для корпоратива в соседнем супермаркете, что не характерно для данного магазина. Такие данные должны отсекаться, чтобы не искажать прогноз. Поэтому мы должны тестировать в том числе некорректные данные, чтобы удостовериться, что прогноз будет верным.
3. Настройка окружения и подготовка данныхСледующий этап — настройка окружения и подготовка данных.Обычно мы выбираем стенд для тестирования, устанавливаем нужное программное обеспечение и создаём тестовые данные — вручную или автоматически через скрипты.В ML всё строже:модель чувствительна к версиям библиотек. Даже небольшое отличие может изменить результат. Поэтому мы на проекте используем стандартную практику — контейнеризацию (Docker), где фиксируем версии.Отдельная задача —защита персональных данных. Для модели нужны данные, близкие к реальным, но без риска раскрытия личной информации. Мы решаем это через хэширование: видим корректные продажи, но не можем связать их с конкретными покупателями.Также важно учитыватьдрейф данных. Со временем данные, на которых обучалась модель, могут меняться. Например, в праздничные дни продажи резко растут, и модель, обученная на «обычных» периодах, начинает ошибаться. Поэтому важно мониторить метрики, чтобы вовремя отследить, когда модель нужно обновить или дообучить.
4. Выполнение тестовЭтот этап – краеугольный камень тестирования. Обычно мы берём написанную тестовую документацию, проверяем функционал и фиксируем результаты прогона.В ML этот этап осложняется отсутствием чёткого ожидаемого результата, как мы уже говорили выше. Здесь нас снова выручают метрики и диапазоны значений.Однако важно помнить, чтометрики сильно зависят от данных. В категории «шоколад» показатели могут быть хорошими, а если спуститься на конкретный бренд, например «Аленку», результаты окажутся хуже. То же самое: хлеб может прогнозироваться точно, а соусы — нет.Чтобы это проверить, мы тестируем модель на разных типах данных. Это могут быть разныеклассы товаров:шоколад, хлеб, соусы. Такой подход позволяет увидеть картину не только «в среднем по больнице», но и в деталях.Модели обучаются на больших объёмах данных, но тестировать их целиком — слишком долго и очень затратно. Поэтому мы тестируем выборку: ограниченный, но максимально разнообразный набор супермаркетов, разного размера, формата и специфики. Это быстрее и при этом даёт нам представление о качестве модели.Важно помнить, что ошибки в ML могут бытьне только в коде.Также встречаются:Дрейф данных: когда текущие данные начинают сильно отличаться от тех, на которых обучалась модель, и точность прогноза падает.Системные баги: ошибки на уровне инфраструктуры или интеграций. Например, если ночной процесс передачи данных о продажах из системы (Spar) задержался или «упал», то утром бизнес не получит прогноз вовремя. Это не баг модели, но для клиента результат будет тот же — прогноз не готов.Поэтому тестирование ML требует учитывать не только качество кода, но и стабильность данных, инфраструктуры и процессов вокруг модели.
5. РегрессияЭто самый долгий этап, потому что нужно проверить всю систему целиком и подготовить отчёт о качестве продуктаВ ML может случиться так, что одна метрика улучшилась (например, наша основная задача выполнена), а другая ухудшилась. Важно разбирать каждый такой случай: критично ли падение другой метрики сейчас или оно не связано с новым функционалом?Важно находить баланс и расставлять приоритеты между метриками.Иногда новая модель перестаёт решать задачи, которые корректно решала старая. Чтобы этого избежать, мы создаём тестовую документацию и проверяем её перед каждым релизом — так убеждаемся, что старый функционал работает правильно.

Подведём промежуточный итог

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

С ML всё иначе. ML-тестирование больше похоже наработу шеф-повара.Здесь нет точного рецепта: данные меняются, результаты могут отличаться, и систему нужно постоянно «пробовать на вкус». Тестировщик следит за тем, какие ингредиенты (данные) используются, оценивает результат по метрикам, при необходимости предлагает корректировки и решает, готова ли модель к работе. Иногда приходится экспериментировать: строгого рецепта нет, а итог всё равно должен устраивать клиента.

Плюсы тестирования ML

Мы поговорили о том, почему тестировать ML сложно. Но должны же быть у такого подхода свое преимущества? И они есть!

1. Полноценное A/B-тестированиеНовую модель можно запустить параллельно со старой и сравнить их работу в реальных условиях. Это позволяет понять, действительно ли новая версия работает лучше, и принимать решения на основе данных, а не интуиции.
2. Реалистичные данныеДля тестирования используются данные, максимально приближённые к реальным. Благодаря этому можно заранее увидеть, как модель поведёт себя в продакшене, и обнаружить проблемы до релиза.
3. Контроль через метрикиКачество работы модели измеряется метриками. Если показатели начинают ухудшаться, это сразу заметно — и можно вовремя принять меры: дообучить модель или пересмотреть данные.
4. Больше данных — больше сценариевБольшие объёмы данных позволяют проверять больше ситуаций и лучше понимать, как модель ведёт себя в разных условиях.
5. Проверка устойчивости к изменениямМожно тестировать, как модель реагирует на новые условия: сезонность, аномалии, изменения спроса. Это помогает заранее выявить возможные проблемы.

Наши факапы

Все любят слушать про ошибки — у нас они тоже были.

1. Один параметр — грузовик молочкиОднажды система дала аномально высокий прогноз по молочным продуктам: сливочному маслу, сметане и творогу. Причина оказалась банальной — в коде сезонного алгоритма перепутали два почти одинаковых параметра: prediction_share и predict_share.В результате в магазины приехал целый грузовик молочной продукции, а директор магазина был, мягко говоря, удивлён. Творог пришлось продавать с большой скидкой из-за короткого срока годности.Если бы аномалию прогноза заметили на этапе тестирования, эту ситуацию можно было бы предотвратить.
2. Недопрогноз лавашейБывает и обратная ситуация — недопрогноз.После одного из релизов система начала неправильно учитывать недельную сезонность для лавашей. Раньше пики продаж на выходных прогнозировались корректно, но после обновления спрос начал «расти» в середине недели. Так как лаваш — товар с небольшими продажами, проблему заметили не сразу.В итоге перед выходными покупатели приходили за лавашем, а его просто не было в магазинах.Этот кейс показал, насколько важнотестирование вглубь по каждой категории низкого уровня, даже для товаров с небольшими продажами.
3. Когда модель «не знает», что наступил новый годНачало 2025 года оказалось для нас непростым. Модель начала выдавать странные прогнозы по продажам. Оказалось, что она просто «не понимала», что наступил 2025 год — из-за некорректной кодировки типа данных для параметраyear. Система обнаружения аномалий тоже не сработала: новые значения выходили за привычный диапазон, но защита этого не распознала.В результате магазины получили некорректные прогнозы, а команде пришлось срочно корректировать заказы.Этот случай показал, что в ML-тестировании важно:проверять модель на будущих периодах и данных, которых она ещё не видела;контролировать работу системы обнаружения аномалий.

А как вы тестируете ML-продукты? Какие лайфхаки работают у вас? И как вы мониторите дрифт данных?Давайте делиться опытом — именно так появляются лучшие практики. Жду вас в комментариях!