The Dos and Don’ts of QA Automation Framework

Almost 10 years ago, I started a position of QA Automation engineer with COMCAST, at center city Philadelphia, PA. My knowledge at that time, with QA Automation tools, in particular with HP suite: ALM QTP and UFT, was very minimal.

Through the years and after leaving COMCAST, I worked for companies like Yellow Book (HIBU), Bank Of America, Bridgestone and the Federal Reserve bank, I finally learned (I believe) - not only how to create a reliable QA Automation framework, but also, I understood the dependency on the manual Domain.

Some of what I learned during these years, was an outcome, of failing again and again, to do it right And sometimes, watching (some of the) colleagues around me, doing it wrong.  I also, have to admit, some of my mentors were very knowledgeable, but each one of them had Different approach to QA Automation Framework design. 

In order to have a solid QA Automated Framework, the following components are a must:

1. Solid, detailed, well-structured and clear manual test cases libraries.
2. A reliable bridge mechanism between the manual test cases and the automated framework.
3. Solid Automated Framework.

Solid, detailed, well-structured and clear manual test cases libraries.

• A clear definition of the Business modules structure, need to be reflected in the way manual Test Cases libraries are being hosted.
• Identifying reusability of the business flow description, for all the business sub-modules as a whole, as well as for each one of them separately.
• Creating pointers from manual test cases to centralized location of the re-usable test cases.
• Test steps need to be written at the lowest level format, so an Automation engineer can script them to become, automated scripts.
• Identifying the test cases, that will be executed in the future, at a high frequency rate, so they become part of Smoke and Regression libraries.

A reliable bridge mechanism between the manual test cases and the automated framework.

• An open channel of communication between BAs, Manual Test Cases writers and QA Automation Engineers is a must.
• Replicate the Manual test cases, to be automated, the following way into the automated framework:

1. Establishing a naming convention to be kept at the manual domain as well as the automation domain - (For example: M_Login for manual, A_Login for automated)
2. Keeping file management structure and files naming identical, at the manual domain as well as the automation domain.

• Demo automated test scripts to manual test cases writers’ team and gets a sign off.

Solid Automated Framework.

• Coded scripts have to be divided into 4 categories:

1. General functions library (Screen cleaner, Date and time calculator, Data import, etc.).
2. General Business functions library - to serve all business sub-modules.
3. Function libraries dedicated to each one of the business sub-module.
4. Driver script to represent a Test Case (TC), to be associated with all the above. Will include the exact definition of the manual test steps from the manual version.

• Resources:

1. Static data can be: key driven, data driven or hybrid - dedicated to each business sub-module (can be hosted in XLS or MS ACCESS files).
2. Shared Objects Repository (if chosen to be used, instead of descriptive programming) has also to be dedicated to each of the business sub-modules.
3. Authentication and environment configuration can be written in a XML config file.
4. Dynamic data need to be hosted in a global variables class (Private members) or in a Data Dictionary.

• Keep it modular, so a batch execution is possible, even when any Test Case is being pulled out.
• Build the framework clear and simple, so it is easy to maintain.
• Do not over code the framework, so it is easy to debug.
• Do not embed testing data into the code – keep it in data resource.
• Create documentation and a progress matrix to measure velocity.