March 30th, 2023 by Adam Sandman
During a recent product demonstration we were asked to explain how SpiraTest's test case parameters work. One of the key features is the way they can be used recursively to make your test cases more modular and reusable. One of our account managers likened the concept to the way dreams were nested in the popular Science Fiction movie Inception.
What Are Test Case Parameters
When you create test cases in SpiraTest, you can define variables that will used in the description, expected result and/or sample data fields of their test steps. These are called test case parameters.
They are defined on a specific test case and can be given a default value, just like a variable in a programming language:
These parameters can then be used inside the text of the test case steps to represent data items that might change. For example, if you are creating a test for whether a user can login to a website, you might make the URL, web browser name, login and password parameters so that the same test case can be used to test with different browser / server / login / password combinations. To distinguish the parameter from ordinary text, we use the special Ant syntax for variables, namely prefixing with a dollar sign and enclosing in curly brackets:
${variable-name}
Then, when you execute the test case, SpiraTest will dynamically replace all instances of the variable names with the appropriate value. For example, in the test case below, the name of the web browser and the initial URL have been replaced dynamically with actual values:
This means the use of test case parameters is invisible to the person actually running the test, even though as we shall see in the next section, it is incredibly useful to the test case authors.
Why Use Test Case Parameters
There are many reasons to use test case parameters, for example having a test set that contains different tests that are executed with different data, but in the context of this article, we are really considering a specific use case. Imagine that we have to write 100 different test cases for an application, but they all require the user to be logged in as a specific user. One option would be write each test case with its own set of test steps for logging in. However that will be very tedious and means that any change to the login page would require making manual changes to each of the 100 test cases.
Alternatively, you can use a linked test case to have a single, common test case with parameters that is called as the first step from each of the 100 different test cases. In this example you can see we have called the Login to Application test case with the login/password: librarian:
We can then reuse the same common test case in another test case where we can login with either a different user or the same user:
That means any subsequent changes to the login screens will only require us to make changes to the one common test case, and not the 100 different test cases that use this linked step. This is a huge time saving.
But what if our common "Login to Application" test case also uses steps that could be used elsewhere, could it also contain a link??
The Dream inside a Dream...
If you remember the movie Inception, in it the protagonist played by Leonardo DiCaprio is able to go into a dream that contains himself in another dream, essentially a recursive set of dreams that you have to then recursively exit to get back to the real world.
Test case parameters in SpiraTest work the same way, where our common test case can itself include a link to a child test case, for example the one opening up the web browser:
This ability to have multiple-levels of recursive test case parameters gives amazing flexibility to how you create and combine test cases. The parameter values from the parent test cases will flow down multiple levels to each of the nested child test cases. This means you can define thousands of small, building-block tests that are then composed together to give your executable actual test cases. Particularly in agile development projects, where change is a constant factor, this flexibility and reusability means that your tests can keep up with the speed of development.