Robot Framework tips and tricks
Introduction
I should apologize: this section is just a primer before the real tips and tricks. I hope you will read this as well.
2000 customers, 5 clerks
The story is based on real events, but the exact numbers and names have been changed in consideration of the survivors. We left the proportions unchanged, we also did this from the point of view of the survivors.
So, a long time ago, I spent my time testing at a medium-sized company far, far away. It was an open office, I heard everything that happened to the back office staff who worked next to me and managed customer data. I knew about all the gossip at work (unfortunately). This is where I developed the meditation technique to shut out everyone around me while working. But this technique is part of another story.
I noticed a great murmur. Something big was brewing. Year opening. A software error rendered the company’s 2,000 customers inactive at the end of the year. There was a list of who went that way. Due to company policy and external legal requirements, it was not possible to hack into the database. So the 5 colleagues working next to me were given the task of going to the customer profile for each customer and changing the inactive switch to active.
They counted: 15 clicks, one id entry with search and even a comment had to be entered in a field saying “Reactivation of a client deactivated due to a program error”: this is at least 30-45 seconds per client at best. For 2,000 customers, this is rounded up to 17 hours of non-stop human time. Realistically, these 5 clerks each have approx. half a day’s work tod o this. Not exactly the most pleasant chore, so I forgave the grumbling. I was just meditating back into the wonderful world of test case writing when a magic word began to take shape in a corner of my mind reserved for testing. Yes, I saw more and more clearly the curse-breaking magic: data-driven test automation.
There was already a test automation initiative in the company, so it was possible to connect the right threads quickly and after 1.5 hours, all 2,000 users were happily living the carefree life of active customers. The world is saved again.
Abracadabra: Data-driven test automation
The solution to the previous story was that I recorded the reactivation process for a customer with the company’s regular QTP. I didn’t care about making the script look good, I just worked on it enough to make it run stably. I replaced the fixed customer ID with a variable and asked the system to go through the Excel list of customers and extract the value of the ID for each customer, put it in the variable and run the only test created with this value.
The test case reactivated one customer every 7 seconds on average. Thanks to his tireless work, he finished in 50 minutes.
Then, with a small script modification, we even checked back to see if all 2,000 customers were reactivated.
Everyone was happy.
To be continued
QTP is not a cheap tool. In fact, it’s expensive. (For the younger ones, the tool is currently called UFT One.) I can’t say it’s a bad tool, because it does a lot. However, in terms of price/value, Robot Framework is much better than it. In the next section, I will show how you can implement data-driven testing in Robot Framework.
