For over a decade now, many digital product and service companies have been using Test Automation frameworks to facilitate the Quality of their products and services. With that, enormous topics and articles are being discussed.
For over a decade now, many digital product and service companies have been using Test Automation frameworks to facilitate the Quality of their products and services. With that, enormous topics and articles are being discussed, such as best practices and various test automation tools and techniques. But still, many of us face a situation where we question ourselves, “Are we getting benefits from Test Automation? Is the effort worth it ?”
So today, we will discuss how to build a framework that will give these questions measurable answers.
As testing itself is a service of a project, most quality leaders visualize Test Automation as a form of service. This visualization is the core reason for creating an architecture that is not focused on value creation.
Test Automation should be considered as a “Product” and while building it, one should act as “Product Owner” rather than “QA Lead.”
The tangible outcome of this thought is the potential backlog of user stories answering the questions like ‘Why you are building it’ & ‘For whom you are building it’.
Once you have answers to “Why” and “For whom,” you can build the architecture around it. To begin with, choose a very minimal set of cases (2-5) and build a complete solution for this set, including processes for an engineer to write scripts, maintain test data, and create a logging and reporting mechanism.
Make this a usable POC and make it available for the “For whom” audience. Based on their feedback, plan your further milestones with increasing coverage of Test Cases.
As our framework is focused on “For whom,” different execution models are needed for various audiences.
While brainstorming on choosing tools & technology stack for your framework, consider the entire features of your Product (Test Automation).Most of the tools available can automate user actions. What we need to emphasize is “what additional features a particular tool provides beyond automation” (e.g., Reporting libraries, logging mechanisms, community support, browser compatibility, device compatibility, etc.).So, depending on what you have visualized about your Product, you might find one tool suitable and another unsuitable.
It is very important to document your product well. This is again targeted towards multiple audiences. (Contributor of framework, Reviewer of framework, User of framework) IMP sections to have in your documentation:
It is important to ensure that Test automation does not report wrong failures or false alarms. If we consider the Test automation framework a Product, then we should be involved in Testing our product when it is being built. So, it’s better to actually “Test” the test automation scripts.
Also, for the results our product generates, we need to have a process defined for how the results are reviewed by the audience and what actions they take.
This majorly includes tracking:
Again, it is essential to retrospect the journey of your Automation Framework at periodic intervals. It helps to evaluate some success parameters like:
To summarize, if you act as a Product Owner to build a Test Automation Framework as a Product, you will automatically treat the framework development life cycle with all necessary artifacts & process conventions, which eventually results in value-focused features of your framework.
