Challenge 04 - Parameterizing Expected Values

What is the objective?

Now that we have understood the concept of parameterization and the value it brings to driving test data, let us further explore different ways in which we can extend on this.

It is common to think of parametrization as a means to provide "input" values such as username and password for your test logic. Another equally relevant use case for parameterization is to apply the concept for "expected" values. For example, assume that you would like to validate the user profile information for different users. Here, you are not inputting any information on the screen, but validating information on the screen to be correct. 

In this challenge, we will use the concept of parametrization to do exactly this. Verify information on the user profile settings page, such as the user’s name, email ID, and telephone number with parameters for expected values.

We are not going to introduce any new entities, but rather enhance the logic in the “Verify Profile Information” Action.

Automation Steps

Login to your ACCELQ Account and open the Action, “Verify Profile Information”.

Previously, we had hard-coded the expected values for verification to fixed literal values in our logic. This won't be valid when you exercise this logic with two different sets of users.

Step 1: Define Parameters for Expected Values

Define parameters for the expected data items you wish to validate through the test. In this case, user profile data such as name, email ID and telephone number are the data items we want to validate.

Click on the Parameters tab. Follow the instructions to create three parameters called Expected Name, Expected Email Address, and Expected Phone Number.

Step 2: Utilize the Parameters in Your Logic

In this step, you will be replacing the hard-coded values with the just defined parameters. In the Action logic statements,

• Click the username value (text shown as “Thomas”) in the first statement
• Click the icon on the left side to choose “Action Parameters”
• Select the Expected Name parameter from the list

Note: After clicking the literal value ("Thomas"), you can simply start typing the name of the Action parameter and the system will bring up the appropriate suggestions.

Repeat this process for the Email address and phone number as well.

Step 3: Provide Values for the Parameters:

The previous step has replaced the hard-coded values in the logic with the parameters we created. We must now provide the values for these parameters by using Test Cases for the Scenario before the test can run.  

Open the Scenario “Verify Profile Information” and click on the Test Cases tab.

Test Case 1: Verify Retail Account Login

• Expected Name: John
• Expected Email Address: john@qbank.com
• Expected Telephone Number: 9721231234

Test Case 2: Verify Admin Account Login

• Expected Name: Thomas
• Expected Email Address: thomas@qbank.com
• Expected Telephone Number: 2141231234

Run the Test

Now you Run the test and navigate to the Results page (from the “Results” left-nav in ACCELQ). Your test execution report will look like this. You will also notice the two Test Cases listed in the left-nav of the report. In one of the open test results, click on “Inputs” to notice the input values used for the “Verify Profile Information” Action.

Design Considerations

Parameterization to drive reusability

To implement the ideas of design-first, expand your understanding of parameterization and find use cases that allow you to optimize and re-use your Action logic.

Naming Convention, is also a critical design element

It is very important that you choose meaningful parameter names that make "functional" sense. As you notice in this example, our parameter names are clear with the "Expected" prefix and they are also named in full-form with spaces, etc. as needed. Always keep the end-user in mind, who may just go and assemble Scenarios using the Actions you created. Ambiguous or confusing names do not serve this purpose well. ACCELQ particularly eases a lot of restrictions in entity naming, so don't be tempted to use acronyms or "programmatic" conventions.