День добрый!
У меня был примерно такой же опыт общения с продажниками, только я искал систему мониторинга для тестовых серверов (проводили нагрузочное тестирование). Со мной в течении двух часов связался рускоговорящий специалист (звонили из Испании, по-моему) и спрашивал о том для чего нам их система и сколько мы готовы за неё заплатить. Я их поблагодарил, но покупать, конечно, мы ничего не стали. Написали, какую-то свою тулзу за пару дней на C#. На первое время нам её хватило. Так что с продажниками связаться всегда проще - они сами вас найдут и втюхают что-нибудь втридорога.
По-поводу же SoapUI, то мы от него в качестве тула для автоматизации отказались полностью. Чему я несказанно рад. Собственно, я и инициировал данный переход и полностью взял на себя риски данного мероприятия.
Могу сказать, что скорость разработки тестов не только не упала при этом, но и заметно возросла, а время поддержки значительно снизилось.
Недавно я подбивал статистику по автотестам за текущий и предыдущий кварталы и вот что у меня получилось на реальных цифрах:
За 2,5 месяца мы сделали Х тестов на SoapUI, а после этого за 4 месяца на Java было разработано 2,1 * Х тестов (более чем в 2 раза относительно тестов на SoapUI), т.е. на SoapUI у нас выходило в среднем 0,4 Х тестов в месяц, в то время как на Java - 0,525 Х (в месяц), что почти на 30% больше по средне-месячной производительности, относительно разработки на SoapUI. Более того, уже к концу первого месяца мы достигли производительности равной созданию тестов на SoapUI, т.е. в последующие месяцы она была даже выше 30%, а оверхед начальной разработки с нуля на Java не превысил срок в 1 месяц. После этого в целом и общем какой-то законченный “фреймворк” (тьфу-тьфу-тьфу) уже был готов и дальше просто писались тесты. Хотя тут стоит оговорится, что при разработке мы уже дважды проводили значительный рефакторинг и переработку кода всех тестов. Концепция менялась со временем и с появившимися новыми знаниями и потребностями. В дальнейшем скорее всего она также будет продолжать изменяться, т.к. есть еще много вещей, которые хотелось бы улучшить.
По поводу нас, то мы не программисты и даже не супер-пупер автоматизаторы с огромным багажом опыта. Даже Java по сути у нас была новым языком, т.е. изучение языка началось практически с момента перехода на него и отказа от SoapUI, т.е. мы писали тесты и изучали язык и технологии в режиме реального времени 
Какие мы получили от этого преимущества (сравниваю с бесплатной версией SoapUI, но и платная не сильно далеко от неё ушла, а на Java у нас только бесплатные и опенсорсные вещи взяты):
- Как уже показал на примере выше - у нас увеличилась производительность. Причем без изменения команды или других организационных мероприятий. Просто поменяли инструмент.
- У нас намного улучшился контроль разработки (код-ревью, контроль версий). В SoapUI в огромной XML’ке проекта было нереально разобраться что в ней поменялось и не сломалось ли что-то в другом месте.
- Появилась возможность делать параллельно разработку, в отличии от SoapUI, с его монолитным проектом. Там это было либо сложно, либо очень сложно. В Java же можно элементарно разнести задачи, а потом замерджить изменения в git’е в общую ветку.
- Возможность вести разработку в отдельной ветке (dev) и далее вносить стабильный функционал в master-ветку. В SoapUI - это было практически невозможно сделать и обходные пути требовали каких-то ручных действий и ненужных приседаний (отдельные проекты, импорт-экспорт TestSuite и т.п. вещи). Т.е. в Java у нас всегда есть стабильная версия тестов, которую можно гонять в любой момент, при этом мы можем (и уже дважды так делали) значительно переписать код.
- Практически пропала копи-паста, в SoapUI постоянно приходилось копировать логику из теста в тест и в случае изменения в ней - также править её отдельно в каждом тесте. Сами тесты стали более читабельными и понятными. В SoapUI было много непонятных костылей, и логика теста была непонятной обычному непосвященному человеку.
- Уменьшилось время на сопровождение и исправление тестов (хотя тут не до конца верно, т.к. из-за изначальных некоторых неудачных решений у нас возникли в дальнейшем потребности в глобальном рефакторинге). Но если в SoapUI нужно было вручную править каждый отдельный тест, то в Java за счет выделения логики и вынесения в отдельные классы правки делаются минимальные и их проще проверять и контролировать.
- Расширяемость + гибкость + кастомизируемость (отчеты, оповещение по почте, агрегатор ошибок и т.д.)
- Удобство работы с кодом в IDE. Я уже все глаза проплакал пытаясь разобраться в этих мелких закорючках в неудобном редакторе SoapUI. После него IntelliJ IDEA это просто какой-то праздник каждый день.
- Тесты стали более стройными, имеют лучшую читабельность, а также получили значительно больше дополнительных проверок и условий. Которые, в тесты на SoapUI было бы нереально добавлять (этот пункт дополняет пункт 5). Хотя тут, конечно на любителя и кому-то наш код покажется очередным макаронным монстром, но все познается в сравнении. И сравнивая с нашими предыдущими тестами в SoapUI мы видим изменения к лучшему.
- Последний пункт, но не последний по значению! Скорость выполнения самих тестов - при прямом сравнении теста на SoapUI и Java с абсолютно идентичной логикой совпадающей на 100% в обоих тестах, оказалось, что время выполнения теста на Java было в 5 раз быстрее, чем на SoapUI. Запуск был из системы управления тестами с помощью консольной команды. Итог: 4-5 сек на тест в Java против 20 сек тест в SoapUI. Возможно, что это был не очень удачный пример, т.к. на других более сложных примерах у нас такого же огромного прироста не наблюдалось, но там уже не было 100% совпадения по функционалу, поэтому сравнивать было не с чем (на Java тесты стали сложнее и богаче). Хочу еще раз отметить, что данный тест я провел в самом начале, когда еще только готовил переход на Java и был написан этот синтетический тест, который полностью повторял один из имеющихся тестов написанных на SoapUI и использующемуся у нас в регрессионной модели.
Ну, и напоследок дам ссылку на доклад с последнего Selenium Camp’а, где был обзор схожих инструментов, только вместо Java показывали Groovy, что для пользователей SoapUI может быть большим плюсом, т.к. в нем так же используются groovy-скрипты и не нужно много учить заново.
Fabulous tests with Spock and Groovy (Yaroslav Pernerovskyy, Ukraine)
Так что инструментов кроме Java есть много, многие из них уже довольно зрелые и удобные и многое дают прямо из коробки + позволяют работать в очень удобных IDE, а не гробить глаза в неудобных окошках SoapUI.
И что немаловажно - за все это часто даже не просят денег (у меня по крайней мере используется Community-версия IntelliJ IDEA, хотя фишки платной версии и не дают мне покоя… 
)
Может сложиться мнение, что я хейтю SoapUI, но это не так. В своей нише для ручного тестирования данный инструмент весьма неплох и удобен. Позволяет быстро и без особых заморочек настроить его и начать работать. Дернуть сервис, проверить его работу вручную. Даже разрабатывая тесты на Java, можно иногда быстренько что-то протестировать предварительно в SoapUI и это не будет зазорно и даже наоборот весьма удобно и экономит кучу времени и помогает в работе. Возможно, что даже для “непритязтельной” автоматизации “на коленке” или для маленькой системы с небольшой тестовой моделью с одним автоматизатором-разработчиком такой инструмент будет приемлемым решением, особенно на первых парах, когда автоматизации нет вообще, но если ваши потребности выше, то советую глянуть в сторону более “взрослых” решений, тем более что они зачастую не сложнее, а даже проще и удобнее в работе и в целом дают множество других преимуществ (как перечисленные мною выше).
P.S. выше показанные выкладки могут содержать незначительные погрешности в связи с праздниками, отпусками, больничными и т.д. Но они не меняют картину в целом.
P.P.S. возвращаясь к главному вопросу - к деньгам. Данная операция нам ничего не стоила и даже более того - сэкономила значительные средства, время и нервы. Дала возможность по новой взглянуть на свои процессы и находить новые точки для их улучшения, а не тратить все свое время на копи-пастинг кода в SoapUI и бесконечные правки опечаток и т.п. вещи.
testomat.io управление авто тестами
