Introduction
Sorry, this part is just an introduction before the real tip and trick. Hopefully, you’ll read this one too.
2,000 Clients, 5 Administrators
The story is based on real events, although exact numbers and names have been changed to protect the survivors. The ratios, however, have been kept intact — also out of consideration for the survivors.
So, a long time ago, in a moderately large company not too far away, I was spending my days doing testing. It was an open-plan office, and I could hear everything happening around me, including what the back-office colleagues dealing with customer data were doing. I was unfortunately aware of every bit of workplace gossip. This is where I developed a meditation technique to block out everything and everyone around me while working. But that’s a story for another time.
Suddenly, I noticed a wave of discontent. Something big was brewing. It was the start of the new fiscal year. A software bug had set 2,000 clients to an inactive status at year-end. The list of affected clients was available. Due to company policy and external legal requirements, direct database manipulation was not allowed. So, the five colleagues working next to me were tasked with manually accessing each client profile and switching the inactive toggle back to active.
They did the math: 15 clicks, one ID typed in for search, and one comment field had to be filled in with the note: “Client reactivated due to program error.” That’s at least 30–45 seconds per client, on a good day. For 2,000 clients, this added up to roughly 17 hours of uninterrupted work time. Realistically, each of the five administrators was facing about a half-day of tedious work. Not exactly fun, so the grumbling was understandable. I was just about to meditate my way back into the wonderful world of test case writing when a magic phrase started forming in the corner of my test-dedicated mind. Yes, it became clearer and clearer — the spell to break the curse: data-driven test automation.
There was already a test automation initiative in the company, so it was easy to connect the right pieces. And 1.5 hours later, all 2,000 users were happily living their best lives as active clients again. The world had been saved. I may have taken away some robot-like work from the administrators, but they were grateful.
Abracadabra: Data-Driven Test Automation
The solution to the previous story was to use the company’s standard UI test automation tool — QTP — to record the reactivation process for one client. I didn’t bother to make the script beautiful, I just tweaked it until it ran stably. I replaced the recorded client ID with a variable and asked the system to loop through an Excel list of clients, extract the ID for each one, assign it to the variable, and run the one and only test case with that value.
The test case reactivated one client every 7 seconds on average. Thanks to its tireless execution, it finished the job in about 50 minutes.
Afterward, with a small modification to the script, we even verified that all 2,000 clients had been reactivated. (We simply replaced the checkbox-clicking step with one that checked the value instead.)
Everyone was happy.
To Be Continued
QTP wasn’t a cheap tool. Neither is its successor. In fact, it’s expensive.
For the younger generation:
I can’t say it’s a bad tool — it’s actually very capable. But in terms of price-to-value ratio, Robot Framework is far superior. (Last but not least, because Robot Framework is open source and completely free.) In the next part, I’ll show you how to implement data-driven testing using Robot Framework.
