It seems like just the other week we were saying, “Spring’s just around the corner!” Now, it seems like we’re practically stumbling into summer, most without even realizing it. Everyone begins to start wearing shorter and shorter sleeves and crowds flock to the beaches in frenzies. Today, similar to the sleeves everyone is wearing, we’d like to discuss a feature that helps make test building “shorter and shorter.” Today, Jorell and Steve join us from our Chicago team to discuss a popular feature used amongst many of our clients – parameterization.
Jorell, Steve, tell us more about parameterization offered by Qyrus, its use cases, and impact on testing and QA processes?
To talk about parameterization, we first have to introduce data driven testing. Data driven testing is a testing method in which test data is read from a data file, usually in a table or spreadsheet format. In Qyrus, using parameterization allows testers to have a single test script cover a wide range of test cases that can be read from a CSV file.
That’s right, when you want to use parameterization there will be an option on each step that you can enable. A CSV file will become available for download. To keep it simple, we can open it using Excel or Google Sheets and fill in the data that way. Each row in the sheet will represent a test case and each column that appears will represent a step being parameterized.
Data driven testing is nothing new to the industry, but the way that Qyrus implements and takes advantage of it is extremely unique. There’s no doubt that there’s power in the ability to use parameterization to increase test coverage. It’s sure to cause some disruption in a tester’s daily work.
How do you see using parameterization impacting day-to-day operations across organizations?
Parameterization makes testing easier through the use of data driven testing methodology. In this fashion, a user just has to write one script and parameterize it instead of writing multiple scripts.
This promotes reusability, a specific pain point that testers face. In a day-to-day setting, we will see less test building overall. In a Qyrus report, you can see that your test was parameterized. Qyrus will show the number of test cases you have run, the number passed, and failed. Each scenario has a separate report generated – all stitched together into one video along with screenshots for each step.
Reusability is a key factor in a good automation testing solution. Having to rewrite and manage dozens – if not hundreds – of the same test script is tedious. Testers specifically find the reusability factor of Qyrus to be useful. We asked Jorell and Steve to expand more on how other types of users might use this feature.
How might parameterization help testers, developers, and business technologists? What value can they bring?
Well, for testers, this will be just like any other data driven testing method. The key difference is in how tests are built on Qyrus, for the most part. Building tests on Qyrus is easy since everything is done in a codeless manner and making it parameterized is just as easy. But in general, this allows testers to spend more time focusing on test case coverage and less on building.
A developer might have use for this in building and re-using unit tests to cover more than just their base functionality. Parameterization can be extremely useful in that manner. And in terms of a business technologist, for certain test cases and scenarios they, too, can even build and use parameterization. More specifically, they might find use in the reporting capabilities, wherein one report can hold upwards of hundreds of parametrized test reports.
Alright, we’ve certainly established the fact that parameterization is an extremely useful tool, and for more than just a tester. Focusing more on the testing process, we wanted to expand more on what type of impact this feature is making in our users’ testing processes.
What is parameterization’s overall impact on the testing process, such as test building, execution, and reporting?
Generally, we like to split testing into these three different facets: building, execution, and reporting. I would honestly say that parameterization has an impact on all three areas. On the topic of building, we’ve mentioned earlier that parameterization allows testers to use one test script to test across many scenarios. And in general, I would say that that, too, applies to execution.
But the reporting capabilities cannot be underestimated. One thing that I believe we should also mention is how these parameterized tests can all be tied to your CI pipelines, another feature we have covered in the past here. Combining these two features together can lead to a robust testing solution for any client.
Yes, that really is the key. Although on these “Feature Fridays” we only cover one singular feature, it’s the combination of these features that really bring out the power in Qyrus.
The power that Qyrus holds is not in just any singular feature or component, but rather in the culmination and combination of these things. Like building blocks, Qyrus is made of many different pieces and parts. So, what might the competition offer?
Does the same or similar functionality exist without Qyrus, and how do competitors address similar problems?
To my personal knowledge, I do know that competitors have something similar, or at least a form of data driven testing in their platforms but Qyrus makes test building collaborative so all users can see the data.
Another key difference between Qyrus and competitors being the ease of use, simple UI, and the time it takes to set up these parameterized tests. From what I’ve seen, some other tools require you to create the table or data file inside their platform. This is not the case with Qyrus.
That’s right. And before Qyrus, data driven testing was still around. However, the method of how you make data driven tests and provide the data has changed with Qyrus. And on top of that, this would require a high degree of knowledge and lots of time from a skilled tester or developer that knows the application as well as how to write code for these scenarios. That problem is mitigated and now everyone can test faster!
That’s it for today! We hope you enjoyed this week’s Feature Friday and learned quite a bit about our ability to parameterize tests on the Qyrus platform. The impact and usability of this feature cannot be understated. But, more importantly, it’s Friday! Summer is quickly approaching, and with it better weather. Enjoy the weekend and hopefully the amazing weather!
Qyrus provides the ability to reuse the same test scripts without the need to change any attributes, data or values. This helps the customer understand how would their application performs when there is a high load number of customers using the application.
Test Repository is a very huge aspect of the entire test building experience of a user. In this feature the tests are stored in the repository and then can be reused across the different test suites either in Test Lab or Sprint.
Shawbrook was able to deliver releases in a much shorter time using the Web, API, and Business Process testing capabilities of Qyrus. The outcomes this drove were faster time to feedback, increased velocity of deployments, better quality of releases with significantly less effort.