Robot Framework: Data driven test automation 1.

Robot Framework tips and tricks


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.



Nem szeretnél lemaradni az új bejegyzésekről?


egy számítógép képernyője logóval
Szőke Ármin

JMeter: Basics of Result Analysis

JMeter series Introduction Previously in Jmeter series: The basics:  HERE Recording and storing: HERE Creating HTTP(s) request: HERE And we have already „Listenered”: In this

Érdekel a tesztelés világa?

Dolgozz velünk hazai és nemzetközi projekteken

egy csoport ember ül egy asztalnál laptopokkal
egy süti csokireszelékkel
Please note that we use cookies to enhance your experience on this website. By using our website, you acknowledge that we have informed you of this.