Authors
Feature Friday – How to Make Test Building Easier With Manual and Dynamic Service Virtualization
Think about when your car is being serviced, the dreaded moment, but in turn you receive a rental vehicle which stands as a usable alternative until your desired vehicle is available. This is similar to service virtualization with regards to API testing. In this case instead of a car users have the ability to mock API’s. Customizing returns and responses, these act as placeholders to mitigate bottlenecks and developmental halts. But this week’s Feature Friday is not about just service virtualization but the unique ability to dynamically generate API responses simplifying and streamlining API testing and service virtualization capabilities, we interviewed Tim and Dan to learn more.
Tell us more about manual and dynamic service virtualization offered by Qyrus and its use cases.
Tim:
Well, we’ve talked about service virtualization before, but that was purely manual. As a brief recap, service virtualization allows users to mock 3rd party APIs or APIs that are still in development. This helps them continue the testing process without delay. And, manual service virtualization specifically targets testers who need to mock APIs with specific request and response pairs.
Dan:
For example, let’s say I want this specific response and a status code 200 when I provide these path or query parameters. But, if they’re just looking to get some data back from an API for testing purposes, then they can dynamically generate these API responses using our dynamic service virtualization.
Tim:
You can generate the data of an API response and use this data in testing and for testing purposes. You can even go as far as to modify the schema of the data that’s being generated in the API response. That’s the added benefit of using the dynamic service virtualization.
What is this feature’s overall impact on the testing process?
Tim:
This feature predominantly impacts test building and execution. Overall, since we have improved and updated service virtualization as a whole, it’s become more versatile. Things have become easier because we no longer have to manually input long API body responses. Things can be generated now.
Dan:
Overall, it can help to improve test coverage and testing speed. And because of the added effort reduction we can see an overall cost benefit, as well. Processes become more streamlined.
The various ways that this tool can be used can enable faster, more efficient test automation. The great thing about Qyrus is that it is codeless and easy to use for testers of various degrees of knowledge and experience.
How might this feature help testers, developers, and business technologists? What value can this feature bring?
Dan:
Testers might utilize more of the manual service virtualization as they might be looking for specific request and response pairs. This is to allow them to test happy/sad paths in their test processes. However, they might enjoy the added functionality that the dynamic service virtualized APIs can bring.
Tim:
For developers, it can be addressed in multiple ways. Front-end developers would no longer have to wait for APIs to be finished with development in order to continue with certain front-end tasks, they can just mock them. When it comes to developing the back-end, developers would not have to rely on 3rd party APIs for testing and instead can just mockup and dynamically generate all of the data they are looking for.
Dan:
And lastly, a business technologist might utilize the dynamic service visualization feature, but probably not the manual. Overall, these features are more tester and developer focused.
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
Tim:
Some competitors have service virtualization capabilities, but don’t have the ability to dynamically generate these API responses and requests like we have been discussing here. It’s a unique feature to Qyrus.
Dan:
Prior to using Qyrus whatsoever, testers would have to build their own mock server in order to achieve the same functionality. It’s not the hardest thing to do, but getting all of the data is where things become tricky. Returning the variety of data that we do and coding that can be much more time consuming. Otherwise, testers would have to pay extra to utilize 3rd party APIs for testing, as most of the time you have a set limit of calls per month.
The improvement made on Service Virtualization brings testing on Qyrus forward by leaps and bounds. Now, more comprehensive testing can take place without any requirements for setup or manually inputting data.
How do you see this feature impacting day-to-day operations across organizations?
Tim:
Well, overall, it frees the testing and dev teams up from dependencies on 3rd party APIs for doing testing. And additionally, it frees testers up from dependencies on the dev team, such as finishing development of APIs just so testing can occur. Sometimes, things get backed up, we’ve all been there.
Dan:
On top of that, this feature can help take some load off of testers since it promotes reusability. These virtualized APIs can be reused across multiple API tests, including Component tests.
While it is impossible to replace the required API for any given application service virtualization, and specifically dynamic service virtualization offer the ability to continue development and testing while resources, or in this case API’s, are unavailable. This not only allows for steadfast development but also streamlines the testing process. Join us again next week for Feature Friday where we further delve into the corners and cusps of Qyrus’ and how they revolutionize testing.
