Authors
Feature Friday – Effortlessly Test Web and Mobile Apps by Making API Calls From Your Scripts
We all hate it. What, you ask? Having to go to two stores in order to pick up everything you need. Whether that be for a dinner or a party, we all hate having to go to multiple places just to fulfill our needs. One store has chicken and bread? Well, they don’t have avocados. The next store has avocadoes, but not the certain spicy sauce you’re looking for? On to the next one! At Qyrus, we’re here to put a stop to that! Well, not for groceries, but for your testing needs!
A brand new feature that helps cut down the amount of navigation and different services you need to navigate to has entered the Qyrus workspace. Users are now enabled to make API calls directly from web and mobile test scripts. This means, rather than having to create this type of test in the Component service, this same functionality can be achieved in a single testing service, thus cutting down the amount of running around you have to do on the platform. To hear more about it, we’re joined by Tim and Suraj from the Qyrus team!
Tell us more about Qyrus’ ability to call APIs during test execution.
Tim:
Well, for starters, the idea behind this is to enable testers to build out more complex and comprehensive test scripts to help increase test coverage. Basically, a user is able to configure an API call to be made during the test script execution and then use that response data in the next part of the test.
Suraj:
The user is able to choose between a GET, POST, PUT, DELETE, or PATCH API call and then from there configure the parameters and headers straight from within the web script itself. The user then has the option to add data to the request based off of data that might have been saved to a variable in an earlier part of the execution or they have the option to extract data from the API call itself. This capability exists on both web and mobile testing on Qyrus.
What is this feature’s overall impact on the testing process?
Tim:
Overall, it helps in terms of test coverage and execution itself. By providing this to the users, they are able to cover more test scenarios and create more complex scenarios to test complex use cases. Also, in the past, users would have to do this type of testing through the Component service itself. This brings more capabilities and power to web and mobile testing as a whole.
Suraj:
Furthermore, it’s super easy to add into the test script. All the user has to do is choose the API action types and then choose which method they wish to call on the API. From there, making it a seamless experience, everything is done from the same screen: the configuration of headers, parameters, and authentication and the setting of data handlers.
How might this feature help testers, developers, and business technologists? What value can this feature bring?
Suraj:
Testers will find the most use out of this feature. Instead of having to use a whole different service to achieve the same functionality on Qyrus, these API calls can now be made from within the web and mobile scripts itself. Also, configuring these API calls is very simple and straightforward – everything done from the UI and in a codeless fashion.
Tim:
One big difference we feel we should mention, too, is that this is not the same as the test data management API calls that we have discussed in the past. Those API calls save data to tables that can be accessed project-wide by all the different test scripts. However, these API calls and the data it captures is executed during the test – not prior – and is only accessible to that test script – not project-wide.
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Tim:
Yes, similar functionality does exist outside of Qyrus, but not in such a simple and straightforward manner. One of the biggest qualities of Qyrus is that we are a one-stop-shop platform for all testing needs – whether that be for web applications, mobile applications, API testing in specific, or component or omnichannel testing.
Suraj:
On top of all that, Qyrus is a “no code” platform that bases itself off of simplicity. Prior to Qyrus, testers might have to cobble together a framework of possibly multiple different tools in order to achieve this same functionality. And on top of that, a deep understanding and knowledge of testing and coding in general would be required.
How do you see this feature impacting day-to-day operations across organizations?
Tim:
At the very least, building out tests becomes a degree faster compared to before. Instead of having to jump through many steps to build out a similar test script on the Component service – such as building out both tests in their respective services, importing them, wiring them together, and setting up the data handlers and transfers – users only have to do this once on the web or mobile script they’re using.
That about wraps up this week’s Feature Friday! We hope that this has brought some insight into how we do testing here on Qyrus. We like to keep testers focused on the task on hand rather than having them run all around a platform just to achieve a simple task. But, it’ the weekend, and dinner won’t cook itself! Hopefully, everything can be found at one store, but in case you have to run out, remember that Qyrus is just one click away!
