Pillars of Automation Framework Design
Automation Framework Design and Development plays an important role in any automation project and effectiveness of Framework determines effectiveness of test scripts during later stages of project. Hence its very important to understand 4 Pillars of Automation Framework Design by any Automation QA:
Pillar 1: Maintainability
The only constant is change. If the code we write today is going to be hard to maintain in the future, the rework and upkeep cost is going to skyrocket. Nicely written code in my books does not just do the job today, but can keep up with the changes to come in time and be easy to maintain. Every project team must have definition of maintainable code they want to follow as per their needs.
Some of the key pointers for same are:
Naming conventions should be defined and followed.
Code commenting standards outlined and should be able to create code documentation from it.
Code complexity should be to a minimum. Large lines of code must be break down under smaller methods.
Logging of test results. Report logs should not just show what passed and failed, rather should have debug information in there and be an easy read at the same time.
Pillar 2: Re usability
The way automation generates great benefits is by being reusable, so should your individual modules in the code. Re usability should be embedded in everything you do in an automation project.
A major concept here is creating wrappers. Again, from my old embedded lessons (the buzz word today being IoT), for areas which we expect fundamental changes to happen, it’s best not to use them directly, instead create a wrapper on top of them even if it would have just one call in it. This makes enhancements easy and adds lots of portability.
Here are a few places to keep re usability in mind:
Selection of scenarios to automate.
Creating architecture of the project, have separate layers calling / utilizing each other.
Methods within each layer could be used by one another.
Reusable test data.
Smaller tests which could be combined to create larger / use case checking scripts.
Pillar 3: Scalability
Often when teams start with automation they have the immediate goal in mind and the long term picture is taken into account. In most automation projects, there will always be a need to expand the project adding more tests and functionality to it. Therefore, the architecture should be built keeping in mind future scalability. Time and again have I seen projects not able to scale up and the need for a massive rework.
Here are a few places to keep scalability in mind:
As you add more and more scripts in your project, there should not be any memory leaks while running the tests either in sequence or parallel
Any dependent tests must not let other tests to fail
Any new functionality addition not let already written tests to start fail
Must be provision available to integrate with 3rd Party Plugins like ALM, JIRA
Pillar 4: Robustness
The most important pillar for an automation project. The environment in which these scripts are to run is ever changing. The AUT (Application Under Test) is changing, browsers / services are changing even the automation tools / languages are changing. With all this change going on, it’s no surprise automation projects do succumb to robustness issues.
The root cause of flakiness (the automation term for not robust) is when the expected state of the AUT is not matching what the automation code is expecting. Therefore, the main guideline is to identify the possible states the overall system can go into and handle them in the code.
I break this exercise down into two areas, proactive and reactive handlers.
Proactive Handlers:
Proactive handlers are where we know there is a higher possibility of something going wrong and we prevent it before it can happen. A great example would be delays. We know for a modern web application, delays are going to be a problem, use dynamic delays as a standard rule before every action.
Test data would be another one. If you are sure there will be a problem (which most of the time there is), handle it can turn into a problem.
Reactive Handlers:
Reactive handlers are when the state change has happened, and now we want to get back on track, let’s say an unexpected popup appeared. Under this heading most the important tool is event handlers.
Apart from the basic Try{} Catch{} blocks, have event handlers to take care of unexpected events like unwanted popups, a page not loading and so on.
While this post does not prove to be a complete guideline, it’s a food for thought on important aspects of framework design.
Building better QA for tomorrow