Hi. I have some eye issues and normally work with a dark background / high contrast in all apps. I use SoapUI daily and find it difficult to read with the default white background. I did a search on the forum and there was a previous request about a year ago in the SoapUI Pro area for this feature. The only response was that it was not supported. I would like to also request this feature. Thanks!
... View more
Can we, and if so how, use something like intellisense on a custom groovy library? So if we have created some utility functions and keep them in a script folder, or library, can we then reference those scripts and their methods intelligently from a groovy test step?
... View more
When Smart Assertion is created property is used for some values in Valid Value column in Smart Assertion (ReadyAPI v3.9.2). Some values might changed in response so it is nice to use "Populate from Received Data". But it changes all values from response. It would be nice that there would be possibility to save/leave not changed properties.
... View more
See more ideas labeled with:
I would like the ability to mask passwords in the settings.xml file for Composite Project files. Our security team flag this as risk since usernames and passwords are exposed in this file. We would like to continue to use the Auth Repository feature while keeping our project files in Composite format.
... View more
See more ideas labeled with:
Current behaviour: 1) In the additional request headers tab of a SOAP/REST test step I select multiple headers (the selected headers visually are selected by having the color blue = OK). 2) I click on the delete bin button. 3) Only the first header is deleted. Expected behaviour: ALL of the selected headers should be deleted. If a use wants to delete 10 headers he now has to manually select them and delete them one-by-one. This is frustrating. Note: this issue has been around for ages. Additionally: We (luckily) can select and copy the headers properly by doing a select and then Ctrl+C. The feature of copy-pasting request headers might not be really visible in the UI (e.g. there is no "copy" button), but I am very grateful this is possible through Ctrl+C. Might be wise to visually allow this to?
... View more
Current Change:
In ReadyAPI 2.5.0, the soap and rest request run button, and for test steps Add Assertion button were tweaked to make them more prominent (they now include text labels). This itself is fine.
However, as part of this change the position of the buttons was also moved. They're now on the right-side of the destination URI instead of the left side.
Request:
Please put the buttons back to the left-hand side of the URI.
Reasoning for it's usefulness:
1. It's inconsistent design. The run button was ONLY moved to the right side for request test steps and operations. However, test cases, test suites, and JDBC test steps all still have the play button on the left-hand side. This breaks the consistency of the run button placement--people will now sometimes have to go to the left to run, and sometimes go to the right, all depending on what's being run.
2. Long-term users are also extremely used to the run button being on the left side, so it's a nuisance to have to keep moving over to the right side now to use it, when we habbitually go to the left-hand side first.
3. There was no need to move the buttons to the right--it didn't help increase the visibility of the buttons, and it doesn't provide any new benefits.
4. It also breaks certain usage patterns where I sometimes open a test request on a left pane, then one or two other validiton checks to the right of that, and they hit the run buttons from left to right while I'm trouble-shooting something. This works nicely when all buttons are placed on the left-hand side of their tabs.
... View more
Our organization would benefit greatly from integration with Allure Reporting. It would be great if SoapUi could allow for annotations, steps and links to be added directly in test case requests/steps that would then output the appropriate xml that generates the beautiful and detailed allure reports.
http://allure.qatools.ru/
... View more
With the release of ReadyApi 2.0 GetData behavior was changed and we are NOT impressed. Font size is set and unchangeable Column width is set and unchangeable This means that ANY TestSuite, TestCase etc. with names longer than 16 characters all look a like, making it impossible to be efficient as new functionality forces us to MouseOver to be able to find the correct TestCase name. Please at least make the GetData Columns resiazeable, so we can see the names of our TestSuites and TestCases again! See attached file.
... View more
Status:
New Idea
Submitted on
02-22-2022
05:49 AM
Submitted by
Inovalon-Tester
on
02-22-2022
05:49 AM
1) Change the Target Test Case selection from a drop-down single-selection list box to a sub-dialogue that allows multiple Test Cases to be selected and test steps to be selected for each test case. 70% of the time I spend in ReadyAPI is repetitive data entry of cloning assertions one at a time between test cases where the default test case is the one I'm using for the source. 2) Change the default selection of the Assertions from none selected to all selected. No one ever needs none cloned, that's a non-operation.
... View more
See more ideas labeled with:
It would really be helpful if OAuth2 authentication would be enabled for soap-Requesrts just like for Rest APIs. Our application supports this and other clients also. For ReadyAPI we use at the moment BasicAuth as workaround
... View more
See more ideas labeled with:
Status:
Accepted for Discussion
Submitted on
08-10-2017
09:37 PM
Submitted by
kbw
on
08-10-2017
09:37 PM
Enhancement Request: It would be useful if we add an extra "Suite Group", or "Suite Categories" level in the SoapUI test case hierarchy for organizing test suites. This would be a parent of Test Suite. This way you could collapse.expand categories of test suites. This should be an optional level, so that those who just want test suites wouldn't need to have the extra layer of categories. Reasoning for it's usefulness: Currently, in each project, we organize tests by test suite, and test case. There is no broader category than test suite. In a situation where you have multiple APIs that while might mostly be independent, but that do also have interaction with each other, it would be handy to have them all be in a single project. However, if each API itself needs several test suites for testing it, then having multiple APIs in a single project isn't great for organizing your test suites, since they're all in a flat structure at the test suite level. That's one reason for keeping the APIs in different projects, so that you can expand only the test suites for the given API, without seeing a bit list of all the other API's test suites. The most common usage for Suite Groups/Categories would likely be to organize test suites by each API in the project, but their would certainly be other categories that people would come up with.
... View more
Testrunner.sh currently supports the -T option, which allows users to specify which tagged test cases they want to run. However, there is not a flag that allows the user to specify which tags to ignore in your test run. For example, if I tagged test cases with "prototype" I could run only those tests with that specific tag using -T"TestCase prototype". However, if I wanted to run all tests but exclude the prototype tags I currently don't have the ability to do that. Maybe a new tag, or addition of ! into the flag would work? Ex: -T"TestCase !prototype" <----- where ! prefix specifies not to run tests with prototype flag This could even be expanded further where the -T option would support both inclusive and exclusive tags. Ex: -T"TestCase prototype !ignorethese" <---- run all tests that have the prototype flag, but don't run those that have ignorethese flag
... View more
Status:
New Idea
Submitted on
03-05-2020
02:50 AM
Submitted by
HimanshuTayal
on
03-05-2020
02:50 AM

There must be a feature by which i can re-order my Test Steps or Test Cases or Test Suites at once, right now i am able to re-order one by one and it takes lot of time if i have huge number of test-cases.
... View more
See more ideas labeled with:
Status:
Implemented
Submitted on
03-07-2019
07:07 AM
Submitted by
marcus_kobel
on
03-07-2019
07:07 AM
I'm using ReadyAPI 2.5.0.
Please implement a feature where I can search for text pieces accross all test steps, regardless their types.
Right now I can do this by searching through the xml project files, but it's clearly not the best (or most friendly) option.
... View more
Status:
Accepted for Discussion
Submitted on
08-06-2019
12:04 AM
Submitted by
kkotaramesh
on
08-06-2019
12:04 AM
Hello, Just the way we have integration of Ready API to Zephyr cloud, Can we have the same integration wtih Zephyr Server too ? My organisation uses Zephyr server and we are very eagerly looking for the integration of zephyr with Ready API so that once Ready API project runs, Mapped zephyr test cases gets executed.
Currently i see that we have that in Zephyr cloud and not on zephyr server. Can we have it on Zephyr server too. Thanks.
We have a case 00397737 on the same.
... View more
Hi, The latest version of ReadyAPI 3.20.0 seems to fix encrypted properties being displayed as plain text in logs within the ReadyAPI software itself but this does not translate when running the project from Azure DevOps using the "ReadyAPI Test for Azure DevOps task" as encrypted properties are still being exposed there. 1. The project password for the task is in plain text - This property should be masked as anyone who views the task would be able to download and access the encrypted project and its properties. 2. Encrypted properties are displayed in the logs/requests as plain text The password has been encrypted in the custom properties using the "selected properties" project encryption . However, encyrpted properties are being shown in the task logs when a request that uses the properties fail or when logged using groovy script as plain text. This display of encrypted properties as plain text is unacceptable especially when creating production tests so it would be benefical if encyrpted properties are not exposed. Thanks, Kayleigh
... View more
I distinctly remember being able to use a 'Run From Here' option (context menu when right clicking a test case from the Test Suite summary screen i.e. the one where the bars show green and red when a test passes or fails). It seems to be gone in one of the last versions? I can see inside a Test case if you right mouse click on a test step you can select run from here. What happens to me is I have a suite with 20 cases and case 14 fails. I then inspect it and want to run case 15 onwards so in the past I would right mouse click this test case and choose Run From Here ...
... View more
See more ideas labeled with:
It will be nice to have the option to set generic assertion for all the API request in the project , or to select some of the APEs should have the same assertion . meaning of generic assertion - The user will create the assertion and will have the option to set it the over API requests. Motivation - I have hundreds of API requests, more then have of them have the same assertion ,so i need to copy paste them one by one.
... View more
Any clone/move renames testcases/suites/steps to 'Copy of'. That is unnecessary if moved to a location, where no copies of them exists. Why not let me clone one or more teststeps, select a destination, and THEN check if one with the same name exists, and if it does, then let me decide on the name? It is especially annoying when cloning multiple objects, as you can't rename these before the cloning. And it gets even more annoying when you clone TestCases, as the new clone's file on the disk is then named 'Copy of'... ' and if you do not want mismatch between the TC name in ReadyAPi and on the disk (relevant when commiting to GitHub), you then have to manually rename the files on the disk afterwards.
... View more
Would be helpful & efficient if there was a simpler way to compare datasources, especially when working with large data sets where multiple calls to db/json wouldnt be practical. Scenario - Taking the results of a jdbc query & putting it into a datasource file. Then taking the results of a json query & putting that into a datasource file. Now compare the 2 datasource files to make sure the values match.
... View more