Я — Маша Лещинская, 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 генерировать и такие тесты.
Ключ к успеху всё тот же — детальный промт. Модели недостаточно сказать «напиши тест сценария покупки» — ей нужно разжевать. Мы разработали алгоритм промта:
Сначала определи, какие экраны участвуют и какие методы им соответствуют.
Создай классы экранов (Page Object), пропиши в них локаторы для ключевых элементов.
Затем напиши сам тест-метод, который выполняет шаги: клик туда-то, заполнить то-то, проверить то-то.
Учти, что для сетевых запросов нужно использовать мок-ответы (если нужно), сравнить количество вызовов 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.
