Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова 

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

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

И хотя сгенерированный код пока не является «черным ящиком», детали реализации имеют тенденцию размываться по мере роста количества строк кода.

Таким образом, ручное тестирование приложения по-прежнему кажется лучшим способом проверки результата.

Но хотя это делает тестирование БОЛЕЕ важным, это не обязательно означает, что мы увидим больше вакансий для тестировщиков (хоть это и контринтуитивно).

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

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

Итак, как мы можем реально поддерживать высокое качество программного обеспечения?

Вот пять моих прогнозов и возможных последствий.

#1 Тестирование лучше встроится в процесс разработки программного обеспечения

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

Поскольку современные ИИ-инструменты хорошо справляются с генерацией кода, ничто не мешает им генерировать и тесты. Конечно, их всё ещё стоит проверять вручную (см. пункт #2), но наличие тестов, созданных вместе с кодом, уже экономит много времени.

Так по мере итераций новых версий мы избегаем регрессий, прогоняя тесты, сгенерированные на предыдущих итерациях.

#2 Больше агентов и ИИ-решений будут добавлять автоматизацию тестирования

Мы увидим больше агентов и AI-решений, которые будут добавлять автоматизацию тестирования вместе с сгенерированным кодом. Те, кто будет генерировать тесты вместе с кодом, будут сталкиваться с меньшим количеством регрессий и смогут масштабироваться гораздо лучше.

На рынке уже есть решения, которые самостоятельно тестируют сгенерированный код и предотвращают регрессии или ошибки в выводе, прогоняя тесты в фоне и возвращая результаты обратно в LLM, например, Nut.new от Replay.io.

#3 Ручное тестирование будет развиваться, а не исчезнет

Ручное тестирование не исчезнет, но оно станет более детализированным, сосредоточенным на проверке новой функциональности и код-ревью.

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

#4 Хороший дизайн тестов по-прежнему будет высоко цениться

Отличные тест-инженеры понимают, что простого написания кода на Playwright и получения покрытия тестами недостаточно.

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

Например, когда тестовый код генерируется с помощью LLM, процесс генерации направляется опытным тестировщиком и проходит проверку. Это помогает гарантировать качество тестов.

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

#5 Время выполнения приложения и тестов станет большой проблемой

Хотя просмотр трассировки, как это реализовано в Playwright, становится стандартом, обычно мы не имеем такого рода информации в runtime приложения.

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

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

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

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

Но мне интересно ваше мнение. Будет ли спрос на тестирование выше – теперь, когда скорость разработки растёт? Или мы увидим обратную ситуацию?

Обсудить в форуме