Мы запретили программистам писать код и ускорили релизы в 2 раза. Как к этому пришли

Я — Маша Лещинская, Head of QA в Surf. Постоянно вижу, как в мобильной разработке все гонятся за ускорением релизов и внедряют ИИ везде, где можно. Но не видят корень проблемы: раньше поймал ошибку — меньше потратил и быстрее выпустил. Мы в Surf сделали из этого систему: применили shift-left подход, запретили разработчикам писать код, подключили ИИ на каждом этапе и ускорили релизы вдвое.

Мы построили три линии обороны, где AI ловит баги раньше всех. Больше примеров и лайфхаков про внедрение ИИ-технологий — в канале нашего CEO.

Коротко, как работает Shift‑left подход с ИИ

Shift‑left — стратегия, когда ревью переносятся на максимально ранние этапы жизненного цикла разработки. Тестирование перестаёт быть финальным контрольным пунктом перед релизом и становится непрерывной практикой. 

Мы добавили к этому подходу ИИ. Раньше привлечение QA на ранние этапы означало больше ручной работы. Теперь AI помогает нам на нескольких участках процесса: ревью требований, ревью кода/тестов и генерации тест-кейсов/автотестов. Все они вписаны в Shift‑Left конвейер — то есть используются до того, как баги успеют просочиться дальше по цепочке. 

Без человека здесь никуда, иначе рискуем потерять контроль. Мы же хотим, чтобы он был явным, а прогноз релиза более реальным. AI-ассистент при подробном промте ускоряет подготовку тестовой документации и автотестов от 2 до 100 раз. Теперь — подробности. 

Линия обороны 1: Ревью требований с ИИ

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

Сюда подключаем ИИ: тестировщик берет новую спецификацию (например, страницу в Confluence или ТЗ в Jira) и запускает скрипт, который вытаскивает оттуда все содержимое — текст, таблицы, комментарии, ссылки на макеты, даже картинки со схемами. Этот контекст скармливаем языковой модели (в нашем случае — через Cursor с движком Claude) с инструкцией с подробными критериями:

Что делает ИИ? Он пробегает по требованиям и отмечает потенциальные проблемы. Например, в одном случае модель указала: 

«В разделе “Оплата” не описано, что делать, если платеж не проходит. Добавьте кейс отказа оплаты.» 

В другом случае ИИ заметил несостыковку: 

«В пункте 5 сказано, что лимит — 100, а в пункте 8 — что 1000. Нужно уточнить.» 

Вот реальные примеры результатов:

Конечно, решение всегда за человеком. Нейросеть не знает контекста бизнеса, может ошибаться или «галлюцинировать» несуществующие проблемы. Поэтому результат ее работы — это список рекомендаций, который QA тщательно проверят.

Практический эффект: увеличилась полнота ревью. Ошибок стали находить в 1,5–2 раза больше. Если раньше на вдумчивое прочтение и выписывание вопросов уходили часы, то сейчас AI делает первичный проход за минуты. Как результат — требования становятся качественнее до написания первой строчки кода.

Больше про наши эксперименты в разработке с ИИ, их результаты для бизнеса и обзоры умных технологий вроде очков Цукерберга и странных черно-белых телефонов пишет СЕО Surf Владимир Макеев в своем ТГ-канале.

Линия обороны 2: Умное ревью кода и тестов

Следующий рубеж — этап разработки. Здесь традиционно качество обеспечивается код-ревью, единичными тестами, статическим анализом кода. Эти практики никуда не делись: мы активно используем линтеры, static code analysis, форматтеры — всю классику. Но к ним добавился ИИ.

Это выглядит так: разработчик завершил задачу, написал десяток новых методов и поменял пару модулей. Перед тем как открыть pull request коллегам, он может проанализировать diff его изменений. Diff — универсальная вещь, которая помогает с такими процессами:

• Логические ошибки.

• Утечки секретов.

• Неоптимальные циклы, избыточные вызовы.

• Архитектурные гайдлайны, читаемость.

• Ломающее процессы изменение API, контракты.

• Изменение правил расчета, скидок, логики.

Мы применяем такой же подход для кода автотестов. Автоматизаторы пропускают свой тестовый код через AI с вопросом: 

«Все ли сценарии покрыты? Не упустил ли я какие-то граничные случаи?». 

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

Практический эффект: ускорение от 2 до 100 раз. На этом этапе мы избегали написания строк кода и переходили сразу к ревью.

Линия обороны 3: Автогенерация тест-кейсов и автотестов

Самый мощный результат ИИ показал на создании тестовой документации и самих автотестов. Здесь есть два направления: генерация тест-кейсов (проверок) на основе требований и генерация кода автотестов на основе проверок.

Генерация тест-кейсов из требований

Под тест-кейсами я подразумеваю обычные описания проверок (manual test cases) — шаги, ожидаемый результат, проверки UI и т.д., и без привязки к коду. Раньше их писали вручную тестировщики. Теперь львиную долю таких проверок нам генерирует AI.

Как мы это делаем: у нас есть специальный шаблон-промт, куда мы помещаем всю информацию о новой фиче: текст требований, дизайн-макеты и даже спецификации API. Например, для экранов UI мы выгружаем из Figma структуру: какие есть кнопки, поля, метки. Для серверной логики прикладываем выдержки из Swagger (контракты API). Всё это собирается в один большой контекст. 

Мы учли из прошлых ошибок, что AI важно задать чёткую структуру вывода. Поэтому просим генерировать проверки, например, в виде JSON — так модель меньше отвлекается на литературный стиль и выдаёт стандартизированные шаги. Сначала мы просим сделать таск-лист и перечислить названия тестов и краткие описания. Затем вручную проверяем: все ли кейсы учтены? нет ли лишних или повторяющихся? Если чего-то не хватает, можем поправить таск-лист. Когда список нас устраивает, даём команду AI расписать каждый тест подробно: шаги и ожидаемые результаты, добавляя в контекст промт и таск-лист.

Пример: допустим, фича — регистрация с вводом ОТП-кода и заполнением данных. Требования описывают поля (ФИО, номер телефона) и бизнес-правила (имя с буквенными значениями, но доступен знак «-»; обязательность полей). ИИ формирует проверки:

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

Практический результат: процессы ускоряются в 1,5–2,5 раза, а иногда — и в 5 раз. Раньше на написание комплекта тестов по средней фиче у сеньора мог уйти целый день, плюс время на ревью напарником. Сейчас AI выдаёт черновик за считанные минуты, а специалист тратит пару часов на проверку и корректировки. Простые сценарии покрываются молниеносно. Более сложные требуют пары итераций с моделью, но все равно быстрее ручного труда.

Ещё плюс — стабильность и полнота покрытия. ИИ, опираясь на дизайн и swagger, реже забывает про мелочи. Человеку свойственно фокусироваться на бизнес-логике и случайно пропускать какой-нибудь маленький крестик-сброс поля или подпись под кнопкой. LLM же перечислили все элементы — она по списку и прошлась. Теперь у нас QA один справляется там, где раньше работали двое. AI пишет, человек ревьюит.

Генерация автотестов: снапшоты и сценарии

Автоматизация автотестирования — не тавтология, а следующий логичный шаг. Мы научили модель не только писать текстовые сценарии, но и генерировать исходный код автотестов на нужном нам фреймворке (XCTest для iOS, Kaspresso для Android, Playwright для Web, и др.).

Оформлять и создавать сложные end-to-end тесты — задача непростая даже для человека, что уж говорить про AI. Поэтому мы начали с более простого — снапшот-тестов UI. Тест проверяет, что интерфейс отображается корректно (например, сравнивает реальный скриншот экрана с эталонным изображением дизайна). Это шаблонный тест, и модель справляется с его написанием легко.

Наш подход к снапшот-тестам: мы выгружаем из Figma скриншот целевого экрана (эталон) и передаём AI информацию о том, как называется view или компонент в коде. Вот как здесь:

Написать 10 снапшот-тестов можно минут за 15, просто прогоняя разные экраны через AI. Раньше на такое у верстальщика-автоматизатора ушло бы полдня.

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

Сценарные (E2E) тесты — самая сложная часть. Это тесты, которые проходят полный пользовательский путь: например, «поиск товара и оформление заказа» или «регистрация пользователя и восстановление пароля». Здесь задействуются сразу несколько экранов и модулей, множество действий, могут понадобиться тестовые данные, моки ответов сервера и т.д. Мы поставили цель: научить AI генерировать и такие тесты. 

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

1. Сначала определи, какие экраны участвуют и какие методы им соответствуют.

2. Создай классы экранов (Page Object), пропиши в них локаторы для ключевых элементов.

3. Затем напиши сам тест-метод, который выполняет шаги: клик туда-то, заполнить то-то, проверить то-то.

4. Учти, что для сетевых запросов нужно использовать мок-ответы (если нужно), сравнить количество вызовов API и пр.

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

Реальный кейс: мы попросили AI написать тест на сценарий поиска товара в приложении. Нужно было открыть приложение, зайти в раздел каталог, нажать на поиск, ввести запрос, открыть карточку товара из результатов. Сценарий включал 3 разных экрана приложения (главный, поиска и карточки товара) и взаимодействие с API поиска (нужно было подменить ответ, чтобы тест был детерминированным).

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

Конечно, без доработок не обошлось. Мы потратили ещё час, чтобы подкрутить детали: подправить названия некоторых методов, проверить корректность ожидаемых значений, убрать лишние проверки, которые AI вставил «на всякий случай». 

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

Практический результат: скорость написания сценарных тестов выросла до 6 раз. До внедрения ИИ 5–6 сложных сценарных тестов писали около 3–4 дней. Сейчас делаем за полдня.

В чем выгода

Внедрение в shift‑left AI-инструментов заметно преобразило наш процесс разработки:

• Сокращение времени тест-дизайна на 50–150%. Подготовка тестовой документации и сценариев ускорилась. Новые фичи покрываются тестами практически сразу после разработки, без «бутылочного горлышка» на стороне QA.

• Снижение затрат на исправление ошибок. За последние месяцы на проектах с shift-left подходом у нас почти не было критичных доработок в конце спринта — большинство серьезных ошибок вылавливалось заранее.

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

• Предсказуемые релизы без авралов. Благодаря shift-left и AI качество продукта контролируется на протяжении всего цикла. Релизный цикл в среднем ускорился в 2 раза.

• Экономическая эффективность AI. Затраты на AI-инструменты оказались смешными по сравнению с полученным эффектом. Коммерческие API и сервисы стоят копейки. В нашем случае доступ к мощной модели (Claude) обошёлся в ~$40 в месяц за аккаунт. 

Конечно, AI по-прежнему не волшебник: ~10% сгенерированных тестов мы отсекаем как лишние или некорректные, а ~30-40% случаев требуют доработки вручную. Но даже с учётом этого итоговая эффективность высокая. 

Заключение

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