ReadyAPI Feature Requests

We have 5 environments we need to target (CI/CD, DEV, TEST, PROD, SANDBOX).  We have 30 apis with new apis on the horizon.   On average each project will require two environments (for the Auth api and the api under test).  Rather than have 30 copies of the Auth api details (one for each api) we would prefer to externalize "shared" details via the use of xinclude.  That way, when/if the Auth api environment/endpoint details change we only have to apply a single update which will subsequently "trickle down" to all the projects that leverage the shared content.             ... View more

Make the xml request Editor window larger by hiding many things. Here attached the picture and suggestions within.   Many Indian's will work in Laptop's and it makes them very very less productive in terms of small screen window. One solution is to use large TV screen but costwise tixing the application is quite cheaper than buying 100k new TV's.   I have used large screen and i say my productivity increases as i see lot moere stuffs in screen. Please try to give more options under menu bar VIEW so people can disable the view when not needed. For my daily use, i disable most of the items still the window us small for me.   Suggestion:  Area "Projects, Dashboard, Integrations" zone can be made hidden. Or these should be merge these with area "navigate, New Project, New Jira, Monitor API"     Regards, @sanathkd  ... View more

I use SoapUIPro and whilst the product is fantastic it unfortunately is very inefficient for me to use due to the colours used to indicate test case/step outcomes.   I'm red-green colour blind (as would be 8% of all your users), so I have no idea which steps have passed (green) or failed (red) without clicking into each one to see if assertions have failed.   It would be great if there was an option in your UI for alternative colour-coding that is red-green colour blind proof (e.g. if a pass was indicated by blue instead of green).   Thanks, Brad ... View more

In their current implementation 1.) the TestEngine needs to be provided a zip with all required files by the calling client 2.) the TestEngine Jenkins plugin will execute one Project/Suite/Case per Jenkins job   Problem: This setup does not scale to execute many Project/Suite/Case SoapUI tests in a row   Suggestion: ad 1.)  a.) Provide TestEngine the ability to access/checkout GIT repos containing SoapUI Projects  b.) Add an API to TestEngine that will take the Project/Suite/Case/... parameters and pick all required files from above local checkout area --> Like this no files need to be created/transfered to the TestEngine server   What still needs to be done is the specification of the list of Project/Suite/Case to be executed. This could be provided by one or more config files maintained in the GIT repo(s)   ad 2.) In case the TestEngine runs on the Jenkins slave(s), the Jenkins job could - checkout the GIT repo(s) - locate the config file(s) containing the list of /Project/Suite/Case SoapUI Tests in the checkout area (e.g. via parameter) - loop the config file(s) calling the TestEngine API with Project/Suite/Case/... parameters   --> like this - The TestEngine is running as a server (contrary to testruner.sh) - The invocation of many Project/Suite/Case's will run with minimal overhead (presumably msecs instead of secs) - all required files are taken from a repo -> any updates propagate to TestEngine automatically   Remark: This type of automated execution of SoapUI Test from different Project/Suite/Case needs to complemented with a suitable test report (e.g. csv file with Project/Suite/Case/Step, timeStamp, Status, ExecTime, ErrorMsg, ... ... View more

In cases where API responses vary depending on environment and this is not in control of the QA team it would be useful to be able to specify which environments an assertion applies to. This would allow a test step to have different assertions only a subset of which are evaluated in any given environment. ... View more

For all my projects I need to add a lot of parameters. I've setup a compare Loop with a few elements that requires linking those parameters manually with other steps. In these steps the list is unsorted whereas this makes it a long term action to link each of them to the right parameter of the next step. e.g. 1) Groovy Script to fetch the file 2) DataSource to fetch some parameters (or all parameters) from that file for each childnode 3) Property Transfer that will link from Source to Target ==> when selecting the Property from Source you have a sorted list as was created in the "Transfers" section left.  When selecting the target, the properties are unsorted regardless wether you've put it in a specific order in the REST Request or not. If you have a long list, this is a washmash of properties.   It would be great if all lists that are visible and usable in ReadyAPI will show a sorted list as was created.   Thanks in advance.   ... View more

Please add Parameter fields TestCaseTags and TestSuiteTags to the Jenkins Plugin.   Regards Daniel ... View more

Hi All,   I had earlier faced issues while generating a new report template in ReadyAPI wherein the report does not compile/load all the components unless and until i close & reopen the application. As Jasper Reports are integrated into ReadyAPI, the compilation must happen immediately instead of loading the plugins only at the time of startup.   It would be good to see this feature in the next coming versions.   Cheers, Sai Kiran,   ... View more