My experience with Katalon Studio is that we used Katalon for one of our projects, and then I started leveraging Katalon by integrating it with AI tools, AP tools, and aptly tools. Aptly tool is an add-on which we can integrate with the existing Katalon. So we didn't have any licensed tool as such, but I integrated a tool to one of our case studies for our clients and made use of it. Predominantly, I used Katalon without using a license just to show our clients that we can use Katalon full-fledged for one of our automation scripts, which already existed for different tools. That is how I started with Katalon.

Beyond Katalon, I've also worked with other tools, including TestIM, which we used for automating mobile applications and APIs.

For payments, I worked predominantly in the ed-tech domain, enabling a student to select and enroll in courses. This required payment processing where we automated a dummy payment gateway using REST API. The entire enrollment process was seamless, ensuring smooth transitions from selecting courses to payment deductions.

My primary use case for ReadyAPI is for companies dealing more with backend services. ReadyAPI provides services for accessing these services, conducting testing, generating test data, and offers Docker containers for cloud integration. This capability makes it feasible to integrate ReadyAPI right out of the box into any cloud environment, including private and public cloud environments.

I use ReadyAPI for API testing and functional testing. We have transitioned from using SoapUI to using ReadyAPI, and we utilize it for verifying request and response from the backend. We also use ReadyAPI to generate data based on responses, storing it in our internally-created database.

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.

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.

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. 

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 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.

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.

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.

We use the solution for performance testing tools.

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

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 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.

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.

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. 

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

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

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 ReadyAPI for testing APIs.

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. 

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 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.

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 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.

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.

The primary use case is for APIs and API testing.

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

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.

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 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.

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