15 мая Ozon Tech открывает для сообщества два инструмента, которые команда разработала для себя и теперь переводит на них внутренние проекты. Первый — система автоматизации написания тестов на базе адаптивных промптов, которая намеренно обходится без вызовов тяжёлых LLM. Второй — open-source фреймворк Testo для Go с плагинной архитектурой. Оба доклада с практикой, не с теорией.
Контекст
Ozon — одна из крупнейших e-commerce платформ в России. Ozon Tech — инженерное ядро компании, которое обслуживает нагрузки маркетплейса, логистики и финтех-сервисов. Когда такая команда публично рассказывает, как решила конкретную инженерную задачу внутри, это сигнал: паттерн сработал и его не стыдно показать.
QA-автоматизация с помощью ИИ сейчас переживает первую волну хайпа. GitHub Copilot пишет тесты, GPT генерирует моки, стартапы обещают «нулевое ручное тестирование». Но у большинства реальных команд проблема одна: предсказуемость. Сегодня LLM сгенерировал правильный тест, завтра — с галлюцинацией в assert-е. Контролировать это на масштабе сложно.
Именно поэтому подход Ozon Tech заслуживает внимания: они выбрали адаптивные промпты без высокопроизводительных LLM. Это означает меньше стохастики, меньше стоимость вызовов, больше детерминизма — за счёт архитектуры промптинга, а не мощности модели.
Аналитика
В индустрии сложился ложный консенсус: AI в коде = самая большая модель. GPT-4o, Claude Opus, Gemini Ultra — всё туда. Ozon Tech демонстрирует обратный тезис. Если задача хорошо структурирована через адаптивные промпты, для генерации тестов не нужен Opus. Нужна правильная шаблонизация, контекст из кодовой базы и детерминированные правила валидации вывода. Это ближе к RAG-паттерну, чем к «разговору с GPT».
Второй тренд — Go как язык для инфраструктурных инструментов QA. Исторически тестовые фреймворки росли вокруг Java (JUnit, TestNG), Python (pytest) и JS (Jest, Playwright). Go-экосистема скромнее, но спрос растёт вместе с распространением Go в backend-инфраструктуре. Testo с плагинной системой — попытка заполнить этот пробел и дать Go-командам инструмент уровня pytest по гибкости.
Плагинная архитектура критична: она означает, что фреймворк можно расширять под специфику проекта — кастомные репортеры, интеграции с CI, специфические матчеры — без форка core. Это стандарт зрелого инструмента. Если Testo действительно реализует это на уровне pytest-плагинов, это серьёзная заявка для Go-сообщества.
Кейсы применения в бизнесе
B2B-SaaS стартап с командой 5-15 разработчиков. Нет выделенного QA-инженера, тесты пишут сами разработчики в последний момент. Сценарий: внедрить генерацию unit- и integration-тестов через адаптивные промпты на базе лёгкой модели (например, claude-haiku или локальной через Ollama). Промпт берёт сигнатуру функции + docstring + существующие тесты как few-shot — и генерирует новые. Результат: покрытие растёт без найма QA, стоимость вызова на тест — копейки.
Корпорация с legacy-монолитом на Java/Go. Тысячи нетестированных функций, команда QA занята регрессией вручную. Здесь Testo как фреймворк не применишь напрямую (если монолит не на Go), но паттерн адаптивных промптов масштабируется на любой стек. Задача: автоматизировать написание тест-кейсов для новых модулей, которые команда пишет на Go. Подключить Testo как стандарт для новых сервисов, легаси оставить как есть — миграционная стратегия без переписывания.
SMB или агентство в КР/СНГ, разрабатывающее заказной софт. Клиенты требуют покрытие тестами, но бюджет на QA минимальный. Сценарий: встроить генерацию тестов в pipeline через Claude Code + адаптивные промпты прямо в IDE разработчика. Без отдельного QA-специалиста, без дорогих API-вызовов. Это снижает стоимость delivery и повышает доверие клиента к продукту.
Кейсы в личной жизни
Go-разработчик, который избегает написания тестов. Большинство разработчиков пишут тесты по остаточному принципу. Попробуй Testo как альтернативу стандартному testing: плагинная система означает, что можно настроить репортинг под свой workflow (например, вывод в формате, который читает твой CI). Снижение трения = больше тестов.
QA-инженер, который хочет внедрить ИИ, но боится непредсказуемости. Адаптивные промпты — твой вход в тему. Начни с генерации тест-кейсов для документированных API-эндпоинтов: промпт включает OpenAPI-схему + несколько примеров существующих тестов. Модель не придумывает логику — она следует структуре. Предсказуемость высокая.
Студент или джун, изучающий тестирование. Митап онлайн, вход открытый — это редкий шанс посмотреть на production-инструменты изнутри большой команды. Даже если не планируешь работать в e-commerce, архитектурные решения (плагины, адаптивные промпты) применимы в любом стеке.
Как применить сегодня
- Зарегистрируйся на митап Ozon Tech QA 15 мая — он доступен онлайн, без поездки в Москву.
- Найди репозиторий Testo на GitHub (поиск: «ozontech testo go framework») и прочитай README до митапа — вопросы будут конкретнее.
- Если у тебя есть Go-проект с недостаточным покрытием: выбери один пакет, напиши промпт с сигнатурами функций + двумя примерами тестов, попроси любую LLM (haiku, qwen) сгенерировать тесты — оцени качество и предсказуемость результата.
- Для AI-генерации тестов: начни не с «напиши все тесты», а с «напиши тест для функции X с входами Y и ожидаемым результатом Z» — чем уже задача, тем точнее вывод модели.
- После митапа: оцени Testo как стандарт для новых Go-сервисов в своей команде. Плагинная архитектура окупается, когда проектов больше одного.