Тесты, сгенерированные ИИ: когда их предлагать, а не писать

Проблема: просить тесты слишком рано

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

Если никто не определит риск, помощник обычно копирует видимую логику. Он читает условия, входы, выходы и текущее поведение, затем пишет проверки, которые подтверждают, что код соответствует сам себе.

Звучит полезно, но часто пропускает суть. Код показывает, что система делает сегодня. Он не всегда объясняет, зачем правило существует, какой краевой случай навредит клиентам или какая ошибка обойдётся в деньги.

Именно здесь команды теряют время. Они получают аккуратный набор проходящих тестов и считают, что изменение покрыто. На практике мог быть покрыт только очевидный путь, а та единственная ошибка, которая действительно причинит вред, осталась незамеченной.

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

Спросите один простой вопрос перед генерацией: что может пойти не так, если это выйдет сломанным?

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

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

Oleg Sotnikov видел этот паттерн в командах, ориентированных на ИИ. Как только люди определяют риск, помощники помогают значительно. До этого они часто генерируют аккуратные файлы тестов, которые мало что доказывают.

Как уровень риска меняет ответ

Когда код меняется, начните с жёсткого вопроса: что произойдёт, если это не будет работать в продакшене? Ответ скажет вам, нужно ли ассистенту сразу писать тесты или кто‑то должен сначала определить проверки.

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

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

Изменения средне‑рискованности требуют больше заботы. Фильтр поиска, отображение скидки или правило уведомлений могут запутать пользователей и создать тикеты в поддержку. Система продолжает работать, но люди могут принимать неверные решения из‑за непоследовательного поведения. Здесь ассистент может предложить вероятные проверки, но человек должен решить, какие случаи важнее всего.

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

Простое разделение работает хорошо:

• Низкий риск: правки текста, простое форматирование, косметические обновления UI
• Средний риск: пользовательские потоки, влияющие на поведение, но не затрагивающие биллинг, безопасность или правовые правила
• Высокий риск: платежи, права, персональные данные, аудит, соответствие и всё, что клиент может оспорить

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

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

Как знакомство с кодом меняет ответ

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

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

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

Запутанные имена — ещё один красный флаг. Если методы, события или состояния заставляют людей остановиться и спросить: «Что это на самом деле делает?», сначала напишите проверки, разработанные человеком. То же самое касается потоков, которые перескакивают между несколькими сервисами или экранами, прежде чем появится видимый эффект.

Двигаться быстрее можно, когда команда знает фичу из реальной работы, а не из беглого просмотра кода. Разницу обычно чувствуешь сразу. Инженеры могут описать краевые случаи, не открывая пять файлов. Недавние баги были редки и легко объяснимы. Продукт и инженерия согласны, что не должно меняться.

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

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

Простой способ принять решение

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

Добавьте одно предложение о потенциальном вреде. Кого затронет ошибка и что с ними произойдёт? Если один сотрудник увидит неправильную метку, цена мала. Если клиенты не смогут оплатить, войти или получить правильный счёт, цена быстро растёт.

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

Быстрый фильтр достаточен. Можете ли вы описать изменение одним предложением? Маленький ли ущерб, если оно не работает? Знакома ли команда с кодом? Хотите идеи для тестов или доказательства до релиза?

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

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

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

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

Когда ассистенты могут набросать тесты

ИИ‑тесты работают хорошо, когда код «скучный» в хорошем смысле: поведение известно, входы легко перечислить, а выходы просто проверить. В этом случае ассистент не принимает продуктовых решений — он превращает известные правила в тестовые случаи.

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

Это также работает для утилитарного кода, которым команда пользовалась долгое время. Если люди доверяют функции и используют её по всему проекту, ассистент может быстро набросать надёжную базу. Вы всё равно проверите имена, утверждения и пропущенные случаи, но первый проход часто экономит 15–30 минут.

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

Низкорисковая логика форм обычно тоже безопасна, особенно когда правила просты, а граничные значения очевидны. Форма регистрации, принимающая от 3 до 20 символов для имени пользователя — очевидный пример. Ассистент может набросать тесты для 2, 3, 20 и 21 символа без особой опасности, плюс пару некорректных форматов.

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

Когда люди должны сначала проектировать проверки

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

Платежи и восстановление аккаунта относятся к этой группе. Набор тестов может подтвердить, что форма отправляется или что письмо для сброса пароля уходит. Этого недостаточно. Нужно задать более жёсткие вопросы. Что происходит после трёх неудачных попыток платежа? Можно ли восстановить аккаунт после смены и email, и телефона? Блокируют ли механизмы защиты от мошенничества реальных клиентов?

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

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

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

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

После этого ассистент всё ещё полезен. Он может превратить эти сценарии в черновые тесты, расширить покрытие и поймать очевидные пробелы. Но первый ход должен сделать кто‑то, кто знает, как выглядит отказ в реальном бизнесе, а не только в коде.

Реалистичный пример: изменение правил оформления заказа

Интернет‑магазин добавляет правило: доставка в тот же день доступна только при сумме корзины не менее $35. Правило звучит просто, поэтому команда может захотеть ИИ‑тесты сразу.

Ассистент полезен на границах суммы. Он может предложить очевидные проверки: $34.99 должно блокировать доставку в тот же день, $35.00 — разрешать, $35.01 — разрешать, и удаление товара, когда сумма падает ниже $35, должно отключать опцию.

Это хороший пример использования ассистента. Правило ясное, локальное и легко выразимое.

Сложные случаи лежат вне самой суммы. Человек, который хорошо знает поток оформления заказа, спросит, что происходит, когда купон снижает сумму ниже $35. Кто‑то ещё подумает, как учесть магазинный кредит, подарочные карты или налоги при пороге. Саппорт может помнить, что возвраты создают свои проблемы после отправки заказа.

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

Прежде чем выпускать изменение, команде стоит просмотреть неудачные заказы за последний месяц. Это даст реальные паттерны для тестов. Возможно, клиенты часто складывают купоны. Возможно, возвраты создают сложные ситуации в истории заказов. Возможно, доставка в тот же день чаще всего ломается, когда инвентарь меняется во время оплаты.

Ассистент может предложить первый слой тестов. Люди должны спроектировать проверки, которые отражают реальное поведение магазина. Такое сочетание ловит больше проблем, чем быстрый полноценный набор тестов, написанный только по правилу.

Ошибки, которые тратят время

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

Поэтому расплывчатые запросы часто дают аккуратную работу, которая мало что защищает. Вы получаете много проверок по лёгкому пути, а дорогой путь остаётся нетронутым.

Показатели покрытия вызывают похожую проблему. Отчёт может показать высокое покрытие, даже если никто не проверял случаи, приводящие к возвратам, порче данных или блокировке пользователей. ИИ‑тесты быстро поднимают эти числа, что кажется продуктивным. Но это недостаточно. Если тесты только повторяют текущий путь кода, они могут подтвердить баг вместо того, чтобы его найти.

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

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

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

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

Бычная проверка перед запросом

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

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

Держите проверку простой. Спросите, что произойдёт, если изменение провалится в продакшене. Оцените знакомство команды с кодом. Посмотрите старые баги, тикеты поддержки и записи отката. Подумайте о влиянии на пользователя простыми словами. Могут ли кто‑то потерять деньги, доступ или данные? Если да — замедлитесь и аккуратно определите проверки.

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

Небольшой пример проясняет мысль. Допустим, вы меняете правило оформления заказа, чтобы скидка действовала только для новых покупателей. Если команда знает код и правило ясно, ассистент быстро сгенерирует полезные тесты. Если в старых багах есть краевые случаи с возвратами, гостевыми аккаунтами или просроченными купонами, то человеческие проверки обычно лучше, потому что они задают более острые вопросы в первую очередь.

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

Что делать дальше

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

Держите правило достаточно коротким, чтобы поместить в шаблон pull request или командный документ. Если никто не сможет повторить его на память, оно слишком длинное.

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

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

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

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

Некоторым командам нужна помощь, чтобы превратить это в рабочую политику. Oleg Sotnikov делится такими практическими советами Fractional CTO на oleg.is, особенно для стартапов и небольших компаний, которые хотят использовать ИИ в тестировании, доставке и повседневной разработке, не потеряв контроль над риском.