ReadyAPI Test Reviews

I use the product for data, regression, performance, security, and functional testing. 

The product allows us to uncover any potential issues early on.

ReadyAPI Test needs to improve its reporting. While reports provide essential information when issues arise, or tests fail, having more graphical representations directly within the reports would be beneficial. It needs to improve stability and scalability as well. The tool's support is slow, and takes months to reach a solution. 

I have been using the product for two years. 

The tool's deployment was done in-house. 

ReadyAPI Test is expensive, and I rate its pricing a four out of ten. 

I rate ReadyAPI Test a five out of ten. 

We use it for API testing, functional testing, and performance testing. It helps automate testing processes and ensures the quality and reliability of APIs and web services.

The utmost importance lies in the performance of the application.

The current interface is unsatisfactory. Imagine a scenario where, without an improved interface, testing the API becomes challenging. If I request a specific address through the API, it's difficult to ascertain whether it accurately retrieves the information I need. Without a clearer interface, I won't be able to confirm if the API meets my goal of retrieving the required information. Reading the API documentation alone may not provide sufficient insight. Therefore, having a more intuitive interface is crucial for effective testing and validation of the API's functionality. An additional feature that would be beneficial involves scheduling automated tests and defining scenarios based on the results of specific requests.

I have been working with it for one year.

It offers excellent stability capabilities. I would rate it ten out of ten.

It is utilized by a user base ranging from ten to fifteen individuals. 

We were working with Postman previously. We transitioned to ReadyAPI Test because of the limitations in capabilities.

The initial setup was straightforward. You simply have to download it and begin your work.

Depending on the internet speed, the installation process on a PC should take around ten minutes. Both the installation and initial setup are quick and straightforward. Typically, the deployment requires the involvement of one individual that is also responsible for maintenance.

It is free of charge.

I would recommend it. Overall, I would rate it eight out of ten.

We have around 30 testers using the tool to write and update scripts for manual and automated testing. ReadyAPI Test is useful for API testing in a complex environment. For example, when we first started using ReadyAPI, our customer had a mainframe system. He wanted to log in to the mainframe system and use the data to request the payload of an API, so we needed to set up an API to get the response. The values from the response should be equal to those in the database.

Once everything is matched, then your test case is passed. In a single test case, you need to invoke a mainframe, API, and DB environment, then generate a custom Excel report. At the time, we had no reporting tool. Using our custom jobs, you can invoke a mainframe environment from ReadyAPI. ReadyAPI gives you a platform to invoke the custom jobs from the tool, so you can write the code. In ReadyAPI, you can write Java code because a Groovy snippet is almost always Java. 

ReadyAPI has the power to enrich all the technical work. You can achieve any complex task using ReadyAPI. I can also do UI automation with ReadyAPI. In a few test cases, we want to check the API and the equivalent UI. I download a job and write a piece of Groovy or Java code. It's almost the same in ReadyAPI. I can do that in a single test case. ReadyAPI is a powerful tool because you can do anything you want, but only you need to download the right set of jobs and produce the right set of code.

There aren't any plugins for UI automation. You need to make a custom code and download a job to put into the libraries. If it were panelized, then it would be straightforward. It should be in a panel of the tools, so you can add those tools as your test step in your test cases.

For example, it would be nice to have a Selenium plugin available from the menu, where I can select "open browser" and provide the URL.  That URL would be immediately open in the browser. This is like a keyword, and then the Selenium plugin should be there.

I have been using ReadyAPI Test for around six years now.

ReadyAPI has improved since I started using it. In the early days, the tools were crashing, but now they don't. 

ReadyAPI Test is scalable. 

I rate ReadyAPI support eight out of 10.  There is some room for improvement. Because we are paying such a huge cost, we expect more hands-on support from their research and development team. 

Positive

I rate ReadyAPI Test 10 out of 10 for ease of setup. It's straightforward unless you have a code for a license key. You need to in inject a license key if you have that. You can input the license key and it'll be mapped to the server. Sometimes you can put all the licenses on a server and use the IP of that server. You can have a HERE license or an individually tagged license. 

I rate ReadyAPI Test six out of 10 for affordability. The license is costly in Europe. It's almost the same rate in India, but it's more flexible in terms of purchasing power parity. The license should not be more than 5,000 pounds, but it's more than 10,000 pounds now. The licensing plan could be cheaper. They should offer better discounts at scale. 

We have used other tools Smart Pair Complete is more on the UI side, and Jamie is for API performance, whereas ReadyAPI is for API code. ReadyAPI is on the API automation side, but with it allows you to do more custom coding.

I rate ReadyAPI Test eight out of 10.  If you're a tester who is new to ReadyAPI, you should read the documentation thoroughly. Start with the theoretical before you implement it in practice. Before selecting an API automation product, read the documentation and understand its capabilities, so you can easily determine if it's a good fit for your business.

For now, our primary use case is for basic functional testing. We have six people using this solution, they are testers and developers. I'm a software test engineer and we are customers of SoapUI Pro. 

The solution has some good scanning features. It scans API descriptions to generate functional steps and then runs functional tests. It then gives the opportunity to add some assertions and then finally to integrate them into a grid pipeline, like on Jenkins, and generate G-units or generate reports that are in G-units or J-units format.

We chose this tool because it's lightweight, simple and intuitive. It's open software, it has a command-line interface that is very important for integrating later in the bid process and to get decent reporting. It's a good tool. 

I find that I'm fighting with the opportunities to order requests. There's a view where you can add several requests to a URL and if I have a list of several requests I'm not able to sort those requests which is a problem. I'm still not sure whether there is some kind of a test runner for the API of the installed command.

I've been using this solution for a few months. 

I implemented the solution; it was straightforward and took a few minutes. 

I consider it important to have open software solutions that are documented and to have a tool that is implemented according to standards. It's important for me to have a community where I can ask questions or find answers to typical problems. It's good to have some basic functionality in a community version and to step into a tool and then later to pay for licenses.

I rate this solution eight out of 10. 

We use to do end-to-end testing on mobile devices. Our team has about 50 members, but there are around 500 to 600 people in the whole organization.

SoapUI is very useful. Before we started using SoapUI, we had to do everything manually, which is very time-consuming, and there were a few things we couldn't validate. Using SoapUI made everything easier. You can do six to seven hours of work efficiently, and it's more flexible to use. Before, we had a manual Excel sheet folder where all the manual details were located. Let's say I am developing a particular part of it and it is assigned to some other company. Then we wouldn't be able to test it ourselves. Our client would lack confidence if we were doing manual testing. So that's the reason we used to have one or two teams. One would handle the development, and the other did the testing. But once we had been introduced to these automation tools, it was pretty much straightforward. With SoapUI, you can validate the test kits just by looking at the output screen. Now, we don't really need to have separate teams for development and testing. 

We can do all the automations at a nice pace in less time, so we don't need to spend two or three days testing. The times are changing fast with these new technologies and software solutions, so our relationships are fundamentally changed by these tools. In the future, we'll see more advanced versions of these tools, wherein everything will be done by automated processes. One day we'll be able to do complete tests in just five to 10 minutes.

One good feature is SoapUI's URL check, which allows you to check among the applications. I'm not just talking about the ones for Android. It has all kinds of multi-world tests that are really helpful.

In the beginning—I think it may have been the prior version—there was a lot of lag, but as the version updated, the lag decreased. SoapUI would also benefit from some more customization abilities. It's a good interface, but it would be nice if they added the ability to build custom dashboards where the user can do their own bar graphs and pie charts. It would be helpful from a management point of view. That way, the user can easily be able to know the status of the project. 

I have used SoapUI for the past year.

SoapUI is extremely stable, especially compared to the initial versions. The latest versions are very much stable. 

When it comes to scalability, SoapUI has some room for improvement right now. Its integration with iOS and Blackberry needs to be improved. They could add something like an Android signal that SoapUI is currently, which helps us do in-house development with a device.

We never called tech support at all. Mostly, took care of everything in-house. We only rarely experienced any issues. It's not the sort of thing that requires customer care all the time. 

Setting up SoapUI was relatively straightforward. Generally, we don't do the setups ourselves. The IT team takes care of the installation and provides the software to us in development. I believe it takes about 15 minutes, but I'm guessing, so I'm not very sure about that.

They have a partnership with my company. I believe it is essentially a year. They don't go monthly.

I would rate SoapUI nine out of 10. There are many solutions out there in the market, so it's not just SoapUI. But when we consider the SoapUI, it is far more stable. It is far more flexible and easy to use, especially if you consider other automation tools like Selenium IDE. Those are very standard tools wherein you won't get much flexibility. So always have to put in some time on other tools to get results, but in this case, it is more or less flexible, and the features are also getting pretty fast-paced. So yeah, it is beneficial, as the company's, I would say, every issue in the most we can get done. So yeah, it would be helpful for the developers as well as the testers.

Most of our automation is for REST API, and it involves requested response validation, database validation, and some level of UI automation/validation. The UI is done using Selenium, and SoapUI Pro is used for database validation and file-based validation.

We run around 10,000 different validations, including database validations, and we can complete the entire aggregation in less than one hour. This includes file validations, database validations, and response validations. All 10,000 plus the test conditions include all these three types of validations.

The out-of-the-box support for the database is a valuable feature. For example, SoapUI open-source does not have any out-of-the-box support for doing database validations. However, the commercial version of SoapUI Pro has out-of-the-box support for the database.

Along with that, creating an export or import is very much easier in SoapUI Pro compared to that with the open-source version.

SoapUI Pro is an easy option for non-technical staff as well. I'm currently leading a team in a front project, and I've seen that even a non-technical person with pre-guidance can easily pick up the automation. It is very easy for any person to pick up the automation, and that is something that I like about the tool.

It is limited to scope and risk services only. It does have some support for JMS, but it is not out-of-the-box; you have to do some tweaks here and there. They should improve the scope, and the message should not be limited to SOAP and REST services but also include other protocols and message formats so that people who have other requirements, other than SOAP and REST services, can also think of the solution.

Otherwise, if you have 15 to 20% of automation other than SOAP and REST services, you would have to go to some other tools because it is not fully covered by SoapUI Pro.

As for pain points, reporting is one. It's a bit difficult to filter out or to customize the report. It will be an either everything or nothing kind of report. Reporting also should have a flexible customization option.

When I do a 10,000 testing execution, I don't have the option to filter out the report that is generated. This makes it even impossible on a Windows system to open that report because of the size of the file. It will capture each and every request and each and every SQL period, as a result of the SQL period. So, it is too heavy for Windows to handle it.

I have been using it for several years.

We have two kinds of setup: one is for the automation expert, who does the scripting using his workstation, and the other is for aggregation, for which we have it on the cloud. It is on the AWS server (private, specific to a project), which is used for CICB, a tool from the script using Jenkins. So for DevOps, we are using it on AWS.

I don't see any issue with the setup or the working of the tool. We have never faced any major hiccups.

It is customizable with some scripting. We have to have an expert in Groovy or JavaScripting to do the customization. The users of the tool, any team member, with a little bit of guidance and training can do the automation. However, when it comes to customization a team member with scripting experience is required.

We have both junior and senior team members, and associate level staff who are using it, including senior associates and a couple of team leads. This includes both solutions, SoapUI Pro and ServiceV Pro. Altogether, we have around 15 to 17 members in the team who are using the solutions.

I found  that there are lots of communities, so it's very easy to get help. You can go to the forum, and you can also reach out to the technical support team from SmartBear. They will respond maybe in a day or two; they don't want to take that much time. We post it on the community forum as well. Often, someone has already faced the same problem and has a solution that was implemented. So, we just have to get the solution from them. It's very easy to address those issues with API.

We started with the open-source version, but later on as vendor services increased, the scope increased. So, at that time we migrated from open-source to the commercial version of SoapUI Pro.

We are not just using SoapUI Pro; we are also using ServiceV Pro, which is part of the ReadyAPI umbrella. So we are doing virtualization and also API automation using the same tool. For us, it was easy to have a single tool or tool set from a single vendor with all those options included with virtualization or API automation.

Initial setup wise, the local one was straightforward, but doing it on AWS took some time for us. We were doing it for the first time on AWS, so it took some time for us to understand and complete the setup.

The setup was quick and easy, but integration with other servers, for example, the Jenkins server with the AWS server via SoapUI Pro, took some time. Otherwise, installation on just the AWS server took just a couple of minutes, but integrating it and having a working setup took almost a month for us, including all the approvals and the delays around the approvals.

We initially started with the open-source tool, and the automation which we have covered using the commercial version is far better than that by the open-source version or any other tool, that is, 10,000 test cases in less than one hour. That is very impressive.

The licensing is one area with which we have a problem. To give an example, we have team members who are working in shifts. For example, team member A, works the morning shift and team member B works the afternoon shift. It is not possible for us to utilize a single license on a single piece of hardware so that both team members can use it. We have to take out two different licenses for each of the members.

We have found this to be problematic for us because if we have 20 members and 10 members in each shift, it is not possible. The cost also increases when we try to have 20 different licenses, whereas the hardware or the machine is the same machine, which is shared in two different shifts.

I used IBM Green Hat, Datasoft, etc.

We also use ServiceV Pro, which is from the same vendor, SmartBear. ServiceV Pro is used for stubbing, mocking, or virtualization of the services, whereas SoapUI is used to automate the services or the API.

So, if you want to do automation, you can use SoapUI Pro, but if you want to remove any dependencies related to other services and you want to mock or stop it, then you can use ServiceV Pro.

Your choice totally depends on what kind of scope you have. If it is just limited to SOAP and REST services, then SoapUI Pro is the best option. Also, the cost is very much less compared to those of other solutions, for example, DevTest, which is the most expensive tool on the market.

I would recommend that if you have any SOAP or REST service automation requirements that you should try out ReadyAPI, which has an evaluation version of SoapUI for 30 days. You could try it, and if you feel that it is a good fit for your automation requirements, then you should definitely think of SoapUI Pro.

I would rate this solution at nine on a scale from one to ten.

We use the product for functional automation and functional validation. We also use it to write our scripts to check performance in certain cases.

The tool’s scalability is very good. It's easy to incorporate functional automation cases. The product is easy to access. A new user would not need to go through much documentation to use the tool. The manual features are easy.

Automation features are not user-friendly.

I have been using the solution for around three years.

The tool is stable. I haven't seen any issues.

The scalability of the product is good. We can increase users and functional cases.

I had a bit of experience, so the automation was not difficult for me. When I was training an individual who was new to ReadyAPI, it was a bit tough for them to understand things. The initial setup is complex for a new user. I rate the ease of setup an eight out of ten.

Our managers have a point of contact from ReadyAPI who looks into maintenance and other things if we face any issues.

We have SMEs on our team. We rarely reached out to the technical support team of the product. I have never reached out to the support team. I would recommend the solution to any person. Overall, I rate the product a nine out of ten.

The solution saves us a ginormous amount of time. We used to write our own solutions, from small scripts to task web services, so this saves us thousands of hours.

ReadyAPI Test is awesome and a huge time-saver. The groovy scripting is the most valuable feature and it gives us the ability to expand the abilities of the tool. 

The UI could be a bit more flexible. 

I have been using this solution for six years or so. 

The solution is very stable. 

This is a scalable solution. There are about six people using it in our company, and we have plans to increase usage in the future. 

I would rate the technical support as a five out of five. 

Previously, we used our homegrown web client. 

If you don't know the structure of web services, it could be complex to set up. 

We definitely see an ROI from this solution. 

ReadyAPI Test is about $680 per user, per year. 

This solution is definitely worth the cost. I would rate it as a ten out of ten. 

We were using SoapUI to do UI automation.

Using SoapUI's automation suites to run all our test cases saved us a lot of time. Running 300 test cases takes about three to four days. When you automate all that, it takes only two to three hours.

We used SoapUI for Web API Automation as well as UI automation. With SoapUI's automation suites, we were able to make it very easy and readable by any other user. The test cases were written in a given format where we were able to fulfill the prerequisites by the given statement. We were able to very easily load the data into the database as a prerequisite for the UI and input the given steps using the GUI. 

And when we got to the part where we were performing the action in the UI, the integration between Selenium and SoapUI was very easy. In that step, it made it very easy to validate the UI. 

SoapUI is easy to learn. When we get a new tester on the teams, they can pick it up quickly.

SoapUI has a lot of features I like, such as the different data generators and data sources. The looping part of it is also good.

Grouping of the cases is not possible in SoapUI, to my knowledge. When working with critical cases or the, we were not able to group them properly. We can definitely create a suite and add them there, but within a whole suite, we have to identify them, which was not easy.

When we ran a batch of test cases, we were not able to initiate the next batch automatically. When one suite was completed, we had to trigger another the next test suite manually. That means something from one test suite to another. Suppose, there are 10 test cases in the first suite and another 10 in the second. We have to initiate the first 10 cases and then the second. When we were triggering from the project level, it failed to move from the first suite to the second, and I'm not sure why. But that was something maybe related to the code, not the tool.

I used SoapUI on one project in March 2021.

I was using ReadyAPI and SoapUI Pro. Sometimes it would get stuck, so we had to close ReadyAPI and then start it again. This would happen occasionally. 

And we were also integrating Humps JMS with the SoapUI for messaging purposes.  Sometimes it got stuck. We would have to end the task and then do it again.

It was on-premises. So whenever any tester needed it, they can set it up themself. 
It was not on the cloud, so I have not worked on the cloud. 

To activate the license, we had to use technical support from the SoapUI and that was very quick. They respond to emails very promptly. When you email them, they say they will respond in 24 hours, but it doesn't even take them that long.

The setup was a little bit complicated because we need to download the external JAR to support the Oracle database connection. We had to download the extra JAR for the SoapUI. We also had to do the Selenium setup. We need to create folders where we could place these — that Selenium standalone and the JAR. That was a little bit complex but not too bad. This was our first time, but if we had known what to do, then it would have been easy.

It was not straightforward because we had to integrate with Selenium and the external JAR was needed to set it up and automate the UI. But I was still able to do it by myself in two to three hours.

There was a big investment but the company definitely saw a return. The whole integration pack across the whole organization was using SoapUI. All the framework was designed only using SoapUI Pro. Each one of the testers had two licenses: one for the Windows machine and one for UNIX. But the organization definitely benefited because the releases were frequent and the automation was being done. 

I find SoapUI a little bit expensive because if I need to buy a personal license for one year, then it will cost around 700 to 800 pounds. I'm not sure what an enterprise license costs, but from an individual perspective, I found it costly.

So in my project, two tools were used: Postman and SoapUI Pro. In my organization, most use SoapUI Pro because it's easy to use. There are many more automation features actually in the Pro version of the SoapUI. I am not sure about Postman because we were using it a very basic level. I'm not sure whether automation is possible or not in Postman, but in SoapUI Pro it definitely is. 

I would rate SoapUI a seven out of 10. I would love to work on the SoapUI Pro again because it is really a great product. I would say definitely recommend SoapUI. It's a very useful tool and it will enhance your coding skills as well. It will help you learn to write code well. 
The framework is very easy. It's also easy to do functional testing, API testing, and virtualization. I would recommend this tool for anyone who has to do API testing or UI testing.

We use it for testing SOAP protocol API. We also started with the REST API recently. We use it to manually test as well as to automate a few API calls.

SoapUI provides us better usability and better features. People from different domains can use it effectively.

It clearly makes it easy to test APIs based on the SOAP protocol. We are a logistics company, and we have lots of tracking calls coming in. We provide APIs for tracking services, and it makes sense for us to use SoapUI to test them thoroughly.

There are no bugs or glitches, but a few features available only in the Pro version could be made available in the open-source version. Some of the features do not necessarily need to be only available to Pro users. The data generator would be really useful for the open-source version users.

The Pro version can be expensive for some companies.

For automation commands, it should be able to do what SmartBear is doing with ReadyAPI. They could filter on few things and pass on few things to SoapUI. The user database of SoapUI is bigger than ReadyAPI software.

As far as scripting is concerned, there should be consistency. For example, to declare a namespace, different syntaxes are used. Such things should be made consistent across SoapUI.

It is reliable. It has been good so far. 

It is easy to scale. We have around 18 people who use it. We have developers, QA, and customer support. We also have an E-commerce manager.

It is used very extensively because our major APIs are tested and deployed using SoapUI. Our customer care members use it for their day-to-day functions. They mostly use the manual part of it, whereas we do the automation part of it, which has the scope to grow.

If we are facing issues with the tracking calls or any other APIs that we have, a few members are trained to provide customer support. So far, we haven't come across things where we got stuck. They are usually user errors and not software errors.

I contacted SoapUi's tech support only once almost three years ago. I had emailed their tech support, and they responded fairly quickly.

I do the testing. I do not take care of the deployment. In its deployment, two developers were involved. All three of us are also responsible for its maintenance.

It doesn't take too long. Once it is deployed, I need to check if it works as expected, and the behavior is what is expected in production. 

It adds to the productivity of developers and QAs. So, there is definitely a return.

The Pro version can be expensive for some companies. There are no costs in addition to the licensing fees.

I would definitely recommend it to others. It is super easy to master once you know what you need to do.

I would rate this solution a seven out of 10.