ИИ и тесты: как помочь разработчикам сократить технический долг

О причинах роста технического долга, системных способах борьбы с ним и точечных ИИ-помощниках с большими языковыми моделями «под капотом» рассказывает основатель и генеральный директор облачного сервиса для оптимизации логистики VeeRoute Владислав Кудинов. 

Об эксперте

Владислав Кудинов — основатель Veeroute (лучший стартап 2014 года), Workme (инновационное решение в области HR), Greenary Food (сервис доставки здорового питания), Esprito Ventures, ИТ-компании Explyt. В Veeroute руководил внедрением системы VRt Caravan в сети Казпочта, которая охватила более 500 млн отправлений и позволила сэкономить около 4 млрд тенге за счет улучшенной оптимизации. Первый директор бизнес-инкубатора ИТМО (с 2011 по 2014 годы).

Чаще обновления — выше технический долг 

Частота обновлений ПО в последние годы сильно выросла. Согласно исследованию DORA State of DevOps Report 2024, сегодня только 40% команд разработки могут позволить себе делать релизы раз в месяц и реже, 25% — выпускают обновления чаще раза в неделю. Вот три основных причины: 

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

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

• Многие команды разработки перешли на Agile и используют другие подходы с короткими спринтами. В них работа больше ориентирована на частые небольшие релизы. 

В этом классическом треугольнике Хопкинса «Быстро, дешево, качественно» обычно страдает последний пункт. Конечно, если речь не идет о ПО, которое связано с критической информационной инфраструктурой. Здесь нужно работать с оглядкой на ФЗ-187 и приказ ФСТЭК России от 25 декабря 2017 г. №239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры РФ» и выпускать частые релизы не получится. 

Во всех остальных случаях побеждают «быстро» и «дешево». Когда команде нужно каждый раз запускать новые бизнес-фичи, у нее нет времени, чтобы обернуться и исправить когда-то наспех сделанные решения, переписать некачественный код. Приходится идти на компромиссы и, например, отказываться от полноценных тестов. В результате копится технический долг, забирая часть ресурсов на обновления софта. Согласно исследованию McKinsey, этот груз «съедает» до 20% инвестиций на улучшение продукта. 

Два пути борьбы с техническим долгом 

Существует два принципиальным подхода к работе с техническим долгом. Первый – чередовать спринты разработки по целям. Один цикл команда занята фичам для бизнес-департамента, следующий — улучшает код и отдает технический долг. То есть в треугольнике «Быстро, дешево, качественно» мы уходим от скорости в пользу качества, так как изменения в технической части пользователи на короткой дистанции не почувствуют. Меняющих их опыт обновлений станет в два раза меньше.

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

Как упростить работу программистов с тестами 

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

Ускорить подготовку к тестированию позволяет инструмент Selenium. Он облегчает работу за счет фреймворков, но все же требует большого вовлечения программиста. Можно использовать автогенераторы Symflower или Squaretest, однако, и они имеют свои ограничения. Созданные машиной автотесты сложно интерпретировать человеку из-за нечитаемого кода. Он плохо подходит для последующего редактирования, поддержки и повторного применения в обновлениях софта.

Использование искусственного интеллекта и больших языковых моделей (LLM), на первый взгляд, кажется серебряной пулей. В смежном направлении — написании кода — программисты, использовавшие GitHub Copilot, выполняли задачи на 55% быстрее контрольной группы, работавшей без ИИ-помощника. 

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

• Для получения качественного результата от ИИ нужно сформировать подробный запрос (промпт). 

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

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

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

Существуют и другие решения для составления промптов, начиная с простых прокси-сервисов популярных языковых моделей OpenAI, DeepSeek, Google Gemini и заканчивая тяжелыми комплексными продуктами. При выборе подходящего варианта стоит обращать внимание на следующие моменты:

• Зависимость от конкретной языковой модели. Еженедельно в Open Source появляются новые LLM, которые справляются с локальными задачами лучше предыдущих. Решение не должно быть полностью завязано на определенную модель, а должно универсально переключаться между ними. 

• Возможность работы в закрытом контуре. В соответствии с законодательством ряд компаний не может использовать открытые облака из соображений безопасности персональных данных. Продукт должен позволять автономно работать с LLM, развернутой на собственных серверах организации. 

• Интеграция с существующими инструментами разработки и тестирования ПО, такими как IntelliJ IDEA.В заключение стоит отметить, что даже самый совершенный ИИ-инструмент для генерации тестов кода окончательно не решит проблему технического долга. Здесь требуется комплексный подход. Тем не менее, такое решение может стать хорошим помощником для команды,  позволит сократить время на поддержку работоспособности приложения и защитит от регрессий, особенно при еженедельных релизах и обновлениях продукта.