Будут, конечно.
Но я за более прагматичный подход просто. Как бы мне это не было больно осознавать, но заказчику по большому счету плевать на наше тестирование и даже на наши отчеты. Проверял. Не читают. Но вот что их волнует - это чтобы купленное ими ПО работало и не имело дефектов/проблем, выполняло свои функции и приносило компании прибыль (сокращало расходы).
Все остальные штуки, которые интересны нам, это уже для IT-шников: это и удобство сопровождения и разработки и тестируемости и т.д. Как и почему мы достигаем результата заказчику в 99% случаев все равно.
Поэтому я и удивился, что вы отказываетесь от уже сформированной модели на SoapUI с наверняка немалым числом готовых кейсов в пользу полностью нового подхода. Будет ли экономически оправдан данный переход - большой вопрос. Я вот на новом проекте через Java сервисы юзаю, но там и задача другая и сам проект с нуля стартовал. А вот до этого делал на SoapUI и там этот подход остался и дальше себе тихо и мирно развивается. Потому что снова писать тесты это время и деньги, которых может и не быть, а также возможные баги в самих тестах, которые нужно править, а эти уже есть и работают и ловят ошибки и проверены временем. Как-то так. Но SoapUI я когда-то выбирал просто потому, что особо и не из чего было выбирать и на первых парах с ним было удобно работать. Сразу из ручного сценария делать автоматизированный в одной и той же среде.
P.S. при запуске через консоль у меня память в SoapUI не утекала. А вот через GUI - да, бывали разные вещи. Особенно бесило, когда файл проекта с правками и новыми тестами не сохранялся и вся работа за день псу под хвост.
