Today we bring you an interesting topic “Test Automation Framework” and “Why do we need a framework for test automation?”

The simple answer: For the same reason, we carry a map when commuting and we draw a blueprint before building a house.

Not convinced?

Let us try to find the answer to why the Test Automation framework– through thorough deliberation.

Automation is tricky- not just technically but also economically. It is best suited for areas where there is a substantial amount of tests that have to be repeated across multiple test cycles. And always, Automation Testing happens in addition to Manual Testing or complements it- but cannot, does not and should not replace it altogether.

Now, we testers know that the success of any testing endeavor- Manual or Automation– depends mainly on thorough planning. Typically, we are to spend 1/3 of the entire testing effort on planning- it’s the standard.

This planning usually involves 2 main areas- managerial information like dates, schedules, milestones, people information, etc., and technical testing related information on – Deliverables, how many cycles, tools, data, etc. For an automation project, a framework is everything- a technical implementation guideline, as well as the managerial part of it.

The three technical entities (resources) in an Automation project are:

1. Code-Script
2. Data
3. Objects and their definition on the AUT

The economic (expenditure-wise in addition to the Manual Testing team’s presence) ones are:

1. Tool–licensing: This might also include licenses for additional Add-ins required for the specific AUT on hand
2. Specialized manpower
3. Time- effort in terms of man-hours
4. Infrastructure (could be anything, starting from the physical space you provide for an automation tester to work from.)
5. Test Management tool if using any

In an industry where it is tough to get the buy-in for testing itself (although this has come a long way from where it used to be), it is going to be exceedingly difficult to prove the importance of automation, unless a sure result can be promised.

In other words, we better figure out all the details and assure the success or not venture into automation at all. This is where a solid framework can be the foundation that we need to set foot on solid ground and make sure that we don’t fall.

We are not going to go into the economic aspects in-depth, because we get it. There is an X amount of money put in and we need to make sure that it stays a successful investment.

Why Test Automation Framework?

Let’s try to understand the technical part better:

We all know that a good automation script should launch the AUT, supply the data, perform the operation, iterate/repeat itself as directed, validate and close the AUT, report results and finally, exit. Yes, it is a tall order!

Once we create a script that does all this, it reduces the execution and reporting time (especially if linked to a test management tool) to a few milliseconds as opposed to minutes or even hours. There is no overlooking or a typographic error etc., and overall efficiency is improved.

However, imagine how long it will take to write a perfect script that does it all. How long would it take to understand the test objective, come up with a solution, implement it in code, customize, debug and finalize?

As you see, the real time-consuming factor is the test script creation. The more efficient and time-effective the automation scripts- the better the chances of success.

An example here:

#1) Gmail.com page is the AUT.

#2) Features to test:

• Compose email
• Create contacts
• Receiving an email

#3) Automation testers- assuming each one is working on one feature

Yes, this is a little bit of an oversimplified example. But, personally I feel that there is no concept on earth that cannot be broken down into easy-to-understand pieces. After all, the earth itself is made of tiny atoms.

Now, roughly, the scripts should have code that performs the operations as below:

• Compose Email: Gmail.com launch->Login authorization->Compose email->Write the contents, add attachments(email parameters)->Send email->Logout
• Create Contacts: Gmail.com launch->Login authorization->Select contacts->Create contact->Save->logout
• Receive Email: Gmail.com launch->login authorization->check email->read email-> logout

All the above scripts have to be tested for multiple users with multiple parameters in each operation.

It is clear from the above representation that the following components are Recurring/Repeating:

• Gmail.com launch
• Login authorization
• logout

We can significantly reduce effort and time if we create these components only once and make them available for all the other tests to use as needed – Reusability – create once, debug once, finalize once and reuse many times.

Reusability also makes sure that if a change has to be made, it can be done in a centralized way.

For Example, if the gmail.com home page changes (the first component in every script) – we don’t have to modify each script (3 times in our case). We can simply change it once (in the reusable component) and all the other scripts that use it will automatically use the centrally changed code. This reduces rework and makes sure that changes are consistent overall.

Also, automation scripts recognize the elements on the AUT based on the definitions/properties they store of them. This is yet another major asset for an automation script. If many scripts are accessing the same object, there is no need to duplicate it every time.

A common repository with definitions of the objects can help centralize several small local repositories- again, a huge plus for efficiency.

To summarize – the resources Code and Objects can be optimized by maximum reusability. When components are to be made reusable:

• A correct order has to be followed in creating them (because if we write the code for login last, all the other scripts that need that step can’t be validated in full- same rationale applies to objects as well)
• An identifiable (readable, with-in context) name has to be assigned
• Stored in a location that is accessible and/or available for all the other scripts.

All this information about – What, where, how and when to implement these factors- is part of a framework.

Finally, the Data. You have an option to hard code your data into the code/script- which will force you to create a new script every time a new data has to be supplied. The solution – separate the data from the code. Reuse the code to the maximum and provide the data separately. Again, where will you find the details on how to implement this decision? Framework.

The framework plays a major role in determining how to organize your automation project in order to maximize results. Apart from the above-discussed areas, Framework can also guide the automation testers on how to execute scripts, where to store results, how to present them, etc.

In short, the Test Automation framework is your overall game plan and it can take you where you want to go. So, don’t find yourself without it.

About the author: This article is written by STH team member Swati S.

I hope this article demystified the automation framework for you all. Please let me know your comments and questions on this topic below.