Challenge 03 - Basics of Parameterization

What is the objective?

One of the most common requirements in application testing is the need to exercise a given use case with multiple combinations of input data. Rarely is it enough that you test a particular flow or use case with just one set of hard-coded data and certify the application quality.

For example, a simple test that verifies the Login functionality of our QBank may require you to validate that different types of account holders are able to log in. We may need to verify with the credentials of a retail account holder, commercial account holder, an admin, etc. The verification steps are probably the same for all types of users, but the credentials are different.

Parameterization is a concept that is so ingrained into the testing process and is probably one of the most important components of automation design. We will be sure to build multiple examples on this topic. 

In this challenge, we are not going to introduce any new Scenario, but rather enhance our login verification Scenario with appropriate parameterization.

Automation Steps

Let's log in to your ACCELQ Account and open the Scenario you already created as part of Challenge 01 (Verify QBank Login).

As mentioned before, we are not going to introduce any new entities (Contexts, Actions or Scenarios), but just enhance what we already have.

What information to parameterize?

The first step in building a parameterized test is to review the "information" or "data" that is being used for various steps in the Scenario. And then critically assess each piece of this information to determine if it should be "parameterized" or left alone as hard-coded information.

In this Scenario, we have two items of data we are using as part of the login step. If you open the corresponding Action, you will notice the user name and password are currently hard-coded. To enable us to verify the login test with different user credentials, this information must be parameterized.

Once you determine what information to parameterize, here are the steps to implementing parameterization.

Step 1: Define Input Parameters

Define input parameters for the Action where you are replacing hard-coded information.

In this example, we determined that username and password are the data items we want to replace with parameters. This is part of the Login to QBank Action. Open this Action, and click on the "Parameters" tab. Follow the instructions to create two input parameters called, Username and Password.

Note: You will get a change-impact warning indicating there is going to be an impact on the Scenarios which are using this Action. For now, just click OK to proceed.

Step 2: Utilize the parameters in your logic

In this step, you will be replacing the hard-coded values with the just defined parameters, which act more like a placeholder. In the Action logic statements,

• Click the username value (text that shows as "qbankadmin") in the first statement.
• Click the icon on the left side to choose "Action Parameters".
• Select the "Username" parameter from the list.

Repeat this process for Password as well.

Step 3: Provide values for the parameters

The previous step has replaced the actual user credentials in the logic with the placeholder parameters. But before the test can run, we must somewhere provide values for these parameters.

This is done by defining "test cases" for the Scenario. A test case is an "instance" of a Scenario that represents one data combination to test the flow with. For example, if you define 2 "test cases" for the Scenario, you can repeatedly execute the same steps/flow with 2 sets of data.

Let's define two test cases for this Scenario.

Open the Scenario Verify QBank Login and click on the "Test Cases" tab. Click on "+" icon to add test cases. We will add two test cases.

1. Verify retail account login

• Username: john.todd
• Password: encrypted text for "pass123" (see below note)

2. Verify admin login

• Username: qbank.admin
• Password: encrypted text for "pass123"

Run the test

When you click the "Run" button in the login Scenario, you will now notice that there are two test cases included in it. Click "Run" in the modal and let the tests finish.

Navigate to the Results page (from the "Results" left-nav in ACCELQ). Your test execution report will look like this. You will now notice there are two test cases listed in the left-nav of the report. In one of the open test results, click on the "Inputs" to notice the input values used for the Login Action.

Behind the Scenes

Test Cases bring a multiplicity

With the introduction of Test Cases, we are bringing another dimension to "reusability". In the earlier exercises, we were able to reuse the Actions in multiple Scenarios, thereby reducing the logic "footprint" and improving maintainability.

Combining the concept of parameterization/test cases with a properly modularized Actions design, we have taken the first steps towards a sustainable automation setup.

Impact of new Parameters on Scenarios

When you introduce any new Input Parameters to an existing Action, it is required to furnish values for these parameters in all the Scenarios where this Action was already used. In our case, navigate to other existing Scenarios and create test cases to furnish values for user credentials.