Showing ideas with label SoapUI.
Show all ideas
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
See more ideas labeled with:
-
Automation Environments
-
SoapUI
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
See more ideas labeled with:
-
SoapUI
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
See more ideas labeled with:
-
SoapUI
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
See more ideas labeled with:
-
Automation Environments
-
Scripting
-
SoapUI
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
See more ideas labeled with:
-
Assertions
-
SoapUI
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
See more ideas labeled with:
-
Automation Environments
-
REST
-
SoapUI
Please add Parameter fields TestCaseTags and TestSuiteTags to the Jenkins Plugin.
Regards
Daniel
... View more
See more ideas labeled with:
-
Jenkins
-
SoapUI
Status:
New Idea
Submitted on
02-14-2017
10:46 PM
Submitted by
saikiran40cs
on
02-14-2017
10:46 PM
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
See more ideas labeled with:
-
Reporting
-
SoapUI
It would be great, if ReadyAPI/SoapUI NG would update usages of custom properties in case of renaming the custom property, even if there are used in the value part of the property definiton of "Run Test Case" test steps. 1. Create TestSuite Repro - Custom Property MyRepro 2. Create TestCase Foo - Custom Property MyFoo 3. Create TestCase Bar 3a. Create TestStep "Run TestCase Foo" in TestCase "Bar" 3b. Assign to "MyFoo" the value value ${#TestSuite#MyRepro} 4. Rename the Custom Property "MyRepro" to "MyNewRepro" 5. Check the value in TestStep "Run TestCase Foo" -> Value is still "${#TestSuite#MyRepro}" and not "${#TestSuite#MyNewRepro}" If the custom property is used in a "Soap Request" test step, the usage is updated. So it would be a great help, if same happens in case of usages in "Run TestCase" test steps. With regards
... View more
See more ideas labeled with:
-
SoapUI