Our use case for ReadyAPI is REST API Testing. We essentially test student data because we're working for a school domain that can have different ReadyAPI test cases.

We have the positive test scenario where we collect real-time data and they pass through ReadyAPI, then post different data types for students, such as the school students enrolled in, whether students are full-time or part-time, what courses the students took, etc. There are positive scenarios and negative scenarios that we try to create in the system, including some junk data, then we'll see how ReadyAPI will behave.

ReadyAPI being a tool, means that you can also feed it any junk data, and it's going to post that data, but what we'll be looking forward to is the HTTP code generated towards the end of the day, to see whether it's valid or not.

If there are irrelevant data, for example, there's an address field that can accept any characters, that should be fine, but if we have a name that we need to find and we provide some special characters, then ReadyAPI will give an error message similar to this "Hey, it looks like you're using special characters, so that won't work for me."

There are multiple edge cases, but it isn't about the tool. It's about the applications being used, and there may be some loose ends within the applications. Edge case scenarios could come up, such as the positive scenario and the X, Y, and Z scenario, and ReadyAPI helps us and makes it easy for us by allowing us to post the data. It lets us create multiple test cases, for example, if we have fifteen resources for a test case, we can tightly bundle those resources under one test case, then execute the test case, then ReadyAPI will run everything under that particular test case.

ReadyAPI can be used on the cloud and on-premise, and we are using both methods. We are using the solution locally as a server for test automation. It is local but we are also using Service Pro which is for virtualization and is on the cloud. The integration of the script happens on the dedicated test automation server on the cloud.

We use the solution for coverage of database response validation and service support validation.

I use ReadyAPI for all things API testing – functional, migration, and security testing. It helps me automate tests, ensure reliability, and spot performance issues. The tool offers versatility, especially in virtualizing APIs and integrating with CI/CD.

We have a product, a financial application, that uses a lot of services to connect to our backend systems, so we use ReadyAPI to test those services. Primarily, we use it to build out or mimic the exact services that the development team uses. Second, we use it to build out scripts in Groovy to automate certain scenarios and verify without any manual intervention.

Our company uses the solution's SaaS to provide API testing for customers. 

Our quality and automation engineers use the solution. Senior directors randomly open it to ensure that it is working fine. Everyone thinks the solution is convenient to use. 

Most scripts are developed by automation engineers and used by different groups of people who are only comfortable with manual testing. They run scripts but some have challenges with the solution's Groovy programming at first because they are completely new to programming. Other than that, running scripts and using the tool is quite simple. 

ReadyAPI is where I've created the test tools I've used. I use it for functional testing.

I've used it for testing my code, as in for the unit testing basically, and also the functional tests. We had to perform all types of unit tests. 

We could test all the scenarios of the code, all possible scenarios before it goes to QA. We used Excel files to import the data so that we could test the majority of the data.

Our web application is completely dependent on backend APIs. Instead of automating all the clients' use cases, we make sure that all the backend APIs are automated and are false-proof so that any issues can be tackled upfront. 

On the client side, we have a UI where a user will interact with the application. On that end, it's simply the API that is being called and is fished through the UI that is getting rendered. We capture all those APIs and connect them using ReadyAPI.

We use ReadyAPI to automate our APIs and make sure that all the individual APIs are automated with different possible positive cases and negative cases. Then, we use an end-to-end test where we used to have multiple APIs. In the past, we used to combine all the APIs for a scenario, whereby a particular API would get a value that we would pass to other APIs. In the final result, we have assertions, the Groovy script, which is in ReadyAPI.

I use ReadyAPI for API testing. We have microservices, and we are using it for the API testing on them.

ReadyAPI is predominantly used for functional testing of the APIs. Our company has a lot of micro strategy concepts, and we are building a lot of APIs. The focus is on more validations around the APIs for faster or quicker testing rather than the frontend. 

We are service providers, so a customer will come to us and ask us to build a service. We'll build it, and then we'll use ReadyAPI to test the services before we publish it.

My use cases are mainly for the functional tests of APIs. I have the desktop installation, and I'm using the latest version.

We mainly use this solution for testing APIs, and we also use it for load testing. SmartBear has a free version as well, which is called SoapAPI, but it does not include all of the features we wanted, so we got the paid version. The pro version has many benefits, including the load testing and more features for the API testing as well. Since we are mainly focused on backend testing, we thought it would be useful for us to have this license.

Our primary use case for this solution is for testing APIs, which is very basic. Additionally, we use it for tier-driven automation. For example, if we want a file-based operation for test automation, we can use ReadyAPI as a Groovy scripting tool. So we have some external jars and use Groovy code to invoke mainframe environments, retrieve the data from the mainframe environments into our file, and read the file data. We deploy this solution on the customer's device.

I'm using the solution for API testing. My developer developed their APIs in Postman, so ReadyAPI has this integration factor, and from there, I exported my APIs and imported them into ReadyAPI. Every API I convert into a functional test. 

We are it using it with the license on individual machines.

We have a bulk of APIs for our different products. Previously, we used to do  Postman, and for automation, we used to do C-Sharp code. However, we came to ReadyAPI as it is a tool that can give some exposure to the person who does not have much core coding or programming knowledge. 

ReadyAPI was installed on my system as a client and I used it for microservice API testing. The solution was used for an amusement park.

We use the solution for performance testing tools.

We are using this solution for API testing on HL7 messages for healthcare.

We have a lot of external vendors that we integrate with, so we need to validate all of the APIs. Also, we need to mark those services that don't need external vendor integration.

I'm using ReadyAPI for services, automation, security testing, and manual updates.

We use ReadyAPI to build our own testing cases. We are able to use the same testing cases to complete automation tests, performance test team and security tests at the same time.

We mainly used the different applications of API. It's data-driven, so I had to create the Excel sheet and then loop it through the test suites. We were running each version, which was helpful.

Our organization doesn't have many servers due to security compliance.

We use ReadyAPI for API test automation. These APIs are developed by our development team and we need to validate the response. We use it for manual testing and then automation for those particular manual test cases. This has been my first experience completing API test automation or using tools for this purpose.

We get the data from an Excel sheet and then we input it into the API request to validate the response which we get. That is all done automatically using the automation suit I created on ReadyAPI. We save the data from the response into an Excel sheet. In my team, there are five people who are using it and we have five different licenses.

The primary use of this solution is to perform code testing. We can set up the environment, the representations, and the code coverage.

We have this solution deployed on a Windows station, on-premises.

I primarily use ReadyAPI to convert APIs into functional test cases and to manage customer information.

We were using ReadyAPI for performance testing and creating mocks but there were some issues in terms of scaling, so we are no longer using this solution.

Our primary use case of ReadyAPI is as a testing tool for mock data testing. I'm a technical consultant and we are customers of this solution. 

We use ReadyAPI for testing APIs.

I use ReadyAPI for API and data-driven testing. You can run your APIs through a loop.

The primary use case is for APIs and API testing.

I am a test manager, and we have testers who are experts with these tools. We primarily use this solution for API testing and integration. We have an on-premises deployment.

We are partners with SmartBear and I'm a test architect.

Our primary use case of this solution is to test services to have an understanding of what the request to the service should be and the response. We also use it for performance tests.