Ruth Kusterer is a technical writer for BlazeMeter.

Become a JMeter and Continuous Testing Pro

Start Learning
Slack

Test Your Website Performance NOW! |

arrowPlease enter a URL with http(s)
Jul 20 2021

Resolve, Reuse, Repeat: Optimize the Testing Journey

This story was written based on our experience working with multiple QA team leads across many industries. It does not depict a real person or testimonial.

You may remember my previous blog where I started looking into test automation, and how I evaluated BlazeMeter.com. After recording, the test gets broken down into its building blocks and opens in the Scriptless Scenario Editor, where I can edit and debug it. 

 

 

(It's called "scriptless" because the tester does not need to know any scripting language to create or edit the building blocks of tests. BlazeMeter creates and maintains the scripts in the background.)

 

Debugging My Reusable Login Action

 

Now we come to my "favourite" part of test creation -- debugging... Do you ever debug a script, and it fails simply because it tried to log in, but you were already logged in? 

 

Well, it started happening more often when we started editing and debugging tests in the scenario editor regularly. Do I really have to log off every time before starting another debug session? We first thought we could save time by starting the debugger manually at the first step after the login part. Even though we liked the flexibility that BlazeMeter's local debugger gave us, this workaround was not an ideal solution. 

 

I should mention that BlazeMeter can debug your tests in two different ways: 

  • The first debug option, the “Debug Test" button on the left side, is intended to validate that my test is able to run in the cloud, so I do not have to wait for the test to execute in my local environment. 
  • The second debugger I call “Local”, because it spawns a new browser window and runs everything on my local machine. I use it when I'm quickly fixing a failed test. I look forward to sharing my experience with the local debugger, but it is almost a whole whole application of itself, so I will keep the details for the next blog post.)

 

Debugging With Smart Conditions

 

I had followed the recommended best practice and had saved the login procedure as a reusable Action Group. I found myself staring at the Groups tab, pondering a more robust approach against these unnecessary login hang-ups. 

 

What options does the Scriptless Scenario Editor offer to skip unnecessary steps under certain conditions? I switched over to the Actions tab and took stock. 

 

 

I spotted the "If Else" Action and had an idea. Seeing that scenarios support conditional statements, I knew I could use a little scripting trick to work around my login problem. I needed to model the following condition: 

 

  • If I am on the login page
  • then log on
  • else do nothing and continue without logging on

 

Finding a Suitable Condition

 

I only needed to find a suitable test to identify whether I was on the login page. I saw the Store Title action and tried to store the page title in a variable, and compared the titles of the pre- and post-login pages. But I realized they had the same title, so in this case I could not use this method to determine on which screen I was. 

 

My second idea was to look for a unique object that was present on the login page, but not on any other pages. What about the Username input field? I entered

 

document.getElementById("username") 

as the If condition. Eureka! This simple JavaScript line turned out to be a reliable way of detecting the login page of my web app. Now all that was left was dragging and dropping my login steps into the Then part of the condition, and leaving the Else part empty.

 

The Finished Reusable Login Action

 

What does this "scriptless script" look like in the Scenario Editor?

 

 

Since I previously had told my team members to use my reusable Login Group, they benefited from this change as soon as I saved and updated the Group. You see how using Groups for common procedures is a big time saver, especially in preparation for future changes. When the login page gets redesigned, I'll just update the reused Group once to update this procedure in all tests. 

 

Rerun the a Test With Different Permissions

 

If-else Actions go very well with reusable Action Groups. Our two longest tests are practically the same for admin users and basic users, and have a lot of reuse. I basically run the same test twice, just for two different users with different permissions, and invoke different assertions. For Admins I want to assert that the "Delete" button is available, and for users that the "Request Deletion" is available instead. 

 

Recently I figured out a way to run the same test multiple times, with different test user credentials, and branch where the paths diverge, by iterating over test data in a spreadsheet!

 

I created a spreadsheet Users.csv that contained columns for usernames and passwords, and a third column for the user role. BlazeMeter interprets the three columns as three variables, the username variable can have the values JoeTester or KimAdmin, the role variable can have the values Admin or User, and so on.

 

 

I uploaded the Users.csv spreadsheet to our Shared Folder, so it would be available for all tests that use these credentials. By attaching a spreadsheet to my test, I can use the data iterations feature, where BlazeMeter runs the test repeatedly, once for each row in the spreadsheet. 

 

In each iteration, the variables are set to the values from one row. In my example, in the first iteration, the username variable will be JoeTester, the password variable will be abc123, and the role variable will be Admin. And for the second iteration, it uses values from the second row.

 

My business logic is:

  • The Login Group now uses this iteration's ${username} and ${password} instead of hardcoded values.
  • The AdminVsUserDelete Group contains a condition. 
    • If this iteration's ${role} is "Admin", then assert that the "DeleteButton" is available. 
    • Else, the role is "User", and I assert that the "RequestDeletionButton" is available instead. 

 


Read more:

 

Start testing now!

 

   
arrowPlease enter a URL with http(s)

Interested in writing for our Blog?Send us a pitch!