Ninja QA

Automation Frameworks - design and planning

During my career, I've had the pleasure and sometimes displeasure of having to build and then maintain automation frameworks for numerous clients. All of them ended up being used and eventually evolved over time to become in some cases something better than envisioned or in some cases they devolved into a monstrosity of high maintenance and aggravation.

Its inevitable that requirements will change when dealing with software development and testing. All we can do is plan ahead and plan for change when it eventually strikes. Anticipate the eventuality that your manager is going to one day tell you that he wants to change the credentials used by 2000 tests, if you plan for this eventuality, you can make those extreme cases easier to resolve if and when they arise.

Decoupling & Cohesion

Anyone who is familiar with object-oriented development principles will know that decoupled code is generally good and cohesion is often the measure of whether something is meaningful. 
These principles are often left out of consideration when it comes to QA Automation Frameworks. After all, we aren't real developers are we?  Wrong...

If you write a script, a program or a piece of code that ends up automating another application, I would put forward that you have taken a step or two towards being a developer. You may not have trained or become qualified to wear the job title of Software Developer, but at the end of the day, you have produced software, as simple as it is...

Why is Decoupling good for an Automation Framework? Or any piece of software for that matter.
Coupling software basically means that you are interlinking modules or segments of an application together in such a way that if one piece changes, lots of the application code has to change to accommodate the change requested.
This turns the task of fixing a bug or changing a small piece of code, into a headache that takes more man-hours and eventually costs the company more money.

Decoupling software or making the software modular helps alleviate this issue by making each piece of software self-contained and highly cohesive. 
If you have all code pertaining to a specific piece of functionality in one place, or in one module - then you will have less changes to make in other areas of your application. It also means that you wont have random pieces of code from one area of functionality sticking out like a sore thumb in the wrong module or library.

This is often achieved using Interfaces or the use of Reflection.
Developers all over the world are reading the word Reflection above and gasping in horror. Reflection is often considered a dirty word when you work in software development and have full control of your code base. I mean... why would you need to use Reflection after all if you can just use an interface. How you achieve the feat of decoupling is not as important as achieving it in itself. Everyone has their personal preferences.
Reflection within object oriented programming is a tool like any others and should not be something to fear. Like XPath, it will only produce good results if used by someone who knows what they are doing.

In the next article, I will explain the issues posed by poorly designed automation frameworks and the necessity for objective planning.





Add comment