Не могу похвастать 1/4 ЗП в 600 евро. Наверно я еще не миддл. И я ни разу не встречал чтобы закупку ПО для работы делал линейный сотрудник на свои кровно-заработанные, но возможно и были прецеденты (кресло и мониторы люди иногда покупали - это правда), к тому же это ПО непонятно как проводить через безопасность и через аудит. В основном такие вещи выносятся на уровень выше и вносятся в штатное расписание по закупкам и делается вовсе другими людьми и отделами, особенно в крупных компаниях. Особенности бюджетирования в крупных компаниях - это тема отдельного разговора. От того, что что-то было или не было закуплено я нисколько не проиграл. Все плюсы/минусы перехода я описал выше и привел примеры с раскладами по своему конкретному проекту. На других проектах и в других условиях все может быть иначе.
А почему сравнивал с бесплатной версией - потому что с нею до этого я работал и сменил бесплатный инструмент на другой бесплатный. Почему я должен был сравнивать с чем-то другим? К тому же, я указал те вещи, которые в платной версии работают несколько иначе и лучше, чем в ограниченной бесплатной версии. При этом в платном ReadyAPI!, хоть и исправили какие-то вещи и добавили кое-какие удобные функции - это все равно не идет ни в какое сравнение с тем, как удобно работать в полноценной среде разработки, например, в IntelliJ IDEA. Мои расклады я все привел выше и ничего нового там добавить нечего.
@Dmitry_Gr не очень понял вашу ситуацию, если вы уже распрощались с SoapUI, то значит уже куда-то смигрировали или вы просто выбросили инструмент и остались без ничего на проекте? Или же вы еще никуда не смигрировали, но у вас накопились “претензии” к SoapUI и вы уже четко для себя решили, что нужно что-то менять и куда-то мигрировать, но еще не нашли куда?
Когда я мигрировал, то смотрел по ситуации на своем проекте и текущим задачам, ресурсам, по рынку и т.д. Более того, переезд не был сразу выполнен и сначала в режиме “партизанской” разработки создавался новый фрейморк и пара тестов, которые бы показали применимость данной технологии и позволили бы уже на цифрах сравнить старое и новое и увидеть какие-то проблемы заранее, особенно с обучением новому инструменту. Тогда-то и смогли замерить реально два однотипных сценария и сравнить их производительность между собой.
Причем первые черновые вещи и тесты писались вообще в полу-процедурном стиле, без особого ООП и всяких паттернов проектирования. Задача была сделать быстро и на коленке, показать результат и сравнить со старым. После этого получить “добро” от нужных людей и начать уже полноценную миграцию. Причем у нас старые тесты до сих пор еще некоторые на SoapUI живут и здравствуют и пока не собираются на покой. Причем эти тесты еще с 2015 года так живут. Просто новое ничего на нём не создаётся и если есть время, то некоторое старое переписывается, но времени обычно нет.
По поводу автоматизации, то я бы на вашем месте глядел в сторону dev-ops разработки и того какие для этого нужны инструменты и что больше подойдет вам (возможно уже имеется и применятся в компании). К сожалению, я пока могу только что-то из мира java вам посоветовать, но думаю, что с SoapUI проще всего именно туда переходить, все-таки там Groovy был и он тоже из мира Java.
testomat.io управление авто тестами