Изменения

м
Нет описания правки
Реальная практика идет по другому пути. Подробные спецификации буксуют из-за объема и сложности проверки. Вместо идей и ТЗ бизнес приносит готовые прототипы, созданные с помощью вайбкодинга без спецификации. Но, бизнес готов формулировать acceptance criteria и '''тестировщики могут стать ключевым звеном разработки'''.
В выступлении обсудим, как трансформируются ИТ-процессы и как с помощью '''agentic engineering''' создавать гибридные команды из людей и ИИ-агентов для быстрого и надежного решения задач.  Это выступление - пересборка выступления на [[Как организовать гибридную команду людей и ИИ-агентов (Joker-2026)]], которое было на полторы недели раньше. Тезисы, описывающие ситуацию в ИТ-разработке - сохранились, я не буду их здесь дублировать со страницы выступления. Но были добавлены тезисы, касающиеся возможной роли тестировщика. Они распределены по выступлению, а здесь я их соберу. # Один из работающих вариантов SDD заключается в том, что вместо технического дизайна в спецификацию пишут '''Acceptance criteria и тест-кейсы''', и в таком виде передают агенту для разработки, получается развитие TDD/BDD. В этом случае тестировщик естественным образом занимает '''роль прикладного разработчика'''. Если он работал с автотестами, то представления о коде у него есть, включая работу интеграции. Так что освоение новой роли будет не сильно сложным.# Аналогичная роль прикладного разработчика может быть при разработке прототипов или вайбкодинга приложений по заказу. Тут требуется большее количество навыков аналитика, но они у многих тестировщиков они есть – они взаимодействуют с заказчиком и пользователями для уточнения поведения системы в сложных случаях или разбора инцидентов в рамках поддержки. Кроме того, у тестировщиков обычно хорошие представления о способах интеграции в рамках конкретного ИТ-ландшафта, которые неизбежно потребуются для решения таких задач, чтобы обеспечить вписывание создаваемых сервисов в существующий ИТ-ландшафт.# После того, как для новой фичи или продукта вайбкодингом создан прототип или MVP, который прошел проверку на реальных пользователях в продакшн, это передается ИТ для развития и сопровождения. Его надо обвязать описаниями и тестами, проверить устойчивость и масштабируемость, и провести необходимый реинжиниринг, опираясь на гипотезы о притоке пользователей. В этой команде точно есть место нынешнему тестировщику, работающему с автотестами, особенно если он занимался аспектами устойчивости и масштабирования. # При агентской разработки есть задача мониторинга качества работы агентов и доработки harness в HADI-цикле. И это умеют делать тестировщики, если они работали с системами мониторинга нагруженных приложений в рамках нагрузочного тестирования и решения аналогичных задач. В рамках этих задач при большом масштабе разработки надо не только следить за текущими характеристиками, но и проводить апробацию различных моделей, а для этого нужно создавать наборы тест-кейсов и организовывать оценку. Эти задачи близки тестировщику, особенно если он работал с оценкой и тестированием ИИ-систем предыдущего поколения, например, рекомендательных системы выдачи рекламы и предложений пользователю или чат-ботов.
'''The future of IT: how AI is transforming the industry'''.