Authors
Feature Friday – Bring Relief to Everyone Involved in a Release With API Process Testing
Summer’s half way over, and the dog days are now behind us. Hopefully, this means relief from the hot summer sun and the warm winds that follow behind – also known as perfect football weather (Bear Down!). We here at Qyrus hope to bring relief to the testing world through our unique platform and features that support it! Today on Feature Friday we are going to talk about our API process testing and how it can bring relief to nearly everyone involved in a release from testers to developers. Let’s hear more from our two Qyrus team members joining us today, Tim and Parth.
Tell us more about API process testing using Qyrus and its different use cases.
Tim:
Basically, API process testing is testing the functionality of APIs together in a chain. So, it takes our API functional testing a step further by allowing us to test these complex business flows and processes that we see happen in real day-to-day scenarios.
Parth:
Yeah, so, essentially it is taking data given in one response from an API test and passing it into another. We can chain requests together including one-to-many scenarios – the best part about these tests is the speed – they execute in seconds!
Tim:
Specifically, if clients want to test if their business flows are receiving and sending correct data, then API process testing is right up their alley. This feature also specifically targets clients that want to test the functionality of their end-to-end customer journeys.
That’s fantastic! We can test the functionality of these API processes, rather than just the individual APIs themselves. The impact on the testing process cannot be understated.
What is API process testing’s overall impact on the testing process?
Parth:
Overall, it impacts the testing process at every level. In terms of test building, we allow you to import functional API tests that were built previously. The user also does not have to have any coding experience because it’s all done from our graphical user interface. For execution and reporting, we allow users to parameterize tests for data-driven testing and provide a graphical tree view in the report of the execution along with all individual API reports.
Tim:
One thing to not forget is that it can also connect to CI pipelines, providing an even larger impact by allowing users to be completely hands-off when it comes to execution and reporting of the tests. And overall, we see this feature providing value in terms of an increase in test coverage and a reduction in effort for test building and maintenance.
Parth:
This means that when a build is triggered – first you can execute all functional API tests, assuming those pass – then you can execute your API process tests. With these two steps automated for each build – you will always know whether your API layer is ready for deployment. This means that during your UAT testing – your testers will mainly be focused on the UI. This prevents late-stage discovery of defects leading to increased rework times and possible delays for releases.
The versatility of this feature is no doubt. It can help in many aspects and in a wide array of areas. What kind of help with this feature bring to different types of users, though?
How might API process testing help testers, developers, and business technologists? What value can this feature bring?
Tim:
For testers, using API process testing makes it easier to build these complex API tests and scenarios through importing of old test scripts. Instead of having to individually execute each functional API test, we can string them together. Testers also get the added benefit of the detailed reporting. Developers would see less usage out of this but could be seen using this to almost like unit test their API processes.
Parth:
And for business technologists, you might not see much usage, either. But, because of the graphical nature of these tests, business technologists might find it easier to understand these complex API processes and scenarios. The graphical nature of the reporting works to this end, as well.
It’s been interesting to hear about the different angles that API process testing has on the testing process. But, surely this isn’t something brand new out of the gates? It’s been possible to test API processes in the past…
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Parth:
Outside of Qyrus, you’d find yourself having trouble with finding something that can chain APIs together like Qyrus – especially in a low-code framework! Lots of other similar API testing tools just have the functionality aspect covered, but not the process.
Tim:
And on top of that, most things that do allow for some kind of process testing requires the user to have some coding knowledge. With Qyrus, everything is no-code. We can make these tests without coding, and we can chain them together without coding. All it takes is some basic knowledge.
How do you see this feature impacting day-to-day operations across organizations?
Parth:
By making test building easier by taking coding out of the equation, we often see a large time savings margin. Test building and day-to-day maintenance becomes easier, and reporting makes everything better, as well.
Tim:
We also allow for data-driven testing in API process testing. You can parameterize tests to turn your one chained test into one that can cover dozens if not hundreds of test scenarios – from happy paths scenarios to the most obscure exceptions/negative path test cases. And reusability is there, too, by allowing users to import previously built tests.
It’s true, the benefits of API process testing cannot be denied. The fact that you can parameterize these tests, and connect them to your CI pipeline? What else can we expect?!
Are there any future updates or developments that we might look forward to for API process testing?
Tim:
There are always things that we can improve on. And, although API process testing is a complete feature, we can see future improvements on the roadmap.
Parth:
That honestly goes for everything. If it’s not the feature itself, it’s the user experience behind the feature that can be improved upon. One thing that we’ve thought of doing is allowing for our global variables to be updated after a test execution, allowing those values to become dynamic in a sense.
And that about wraps it up! API process testing is an integral pillar in Qyrus’ API testing , and we see wide usage of it across many of our users. It brings relief where it’s needed most. Speaking of relief, we hope it’s not too hot wherever you are and that you stay cool for the rest of the summer. Join us next week here to hear more about our fabulous features here on Feature Friday!
