Automation Testing -Best Practices
There are a couple of problems we observe in organizations with a large-scale automation testing framework; either they end up struggling with their old model and lack of scalability or they suffer from a huge cost of maintenance. Although we certainly cannot catch up with all the expectations as it is heavily dependent on the budget and priority, there are some common goals that we should set before rolling out the plan and design of a testing framework.
- Decouple your configurable dependencies from your codebase
You will observe your automation team wasting time on updating data and locators which are embedded in their code. Try devising a solution where your test data and locators are fed through a UI dynamically in the runtime, trust me, you are going to save a whole lot of time!
2. Play smart with the test data
We all know that there are restrictions on QA's privileges in the development system, but looking at the efficiency of a DB operation compared to the E2E automation script execution, any of the stakeholders might be willing to join you in your mission. Although this has limitations and drawbacks for multiple reasons, there are ways to handle the exceptions and many organizations have managed to adopt them.
3. Develop a mechanism to update locators dynamically
Looking at the stats where most of our organizations are still focused more on UI testing than API, it is apparent that you will see locator changes in UI testing as a common issue, as most of the Web portals are bound to change periodically. We have no control over it, in fact, we should encourage it to be at par with the competitors.
Handling this one is tricky, but not impossible. I have seen organizations that have an in-house UI framework, keeping a contract with the UI dev makes it possible. This reduces the huge cost of maintenance.
4. Have an independent abstract unit that takes care of the CI/CD, orchestration, and scalability of your system
You might not like to use the same infrastructure that your Development counterpart is using as you create a dependency on them. To make a smooth chain of actions with a high expectation of scalability, you might require a strong DevOps team that provides you with a single entity to take care of the complete pipeline while keeping ample room for enhancement.
Don’t scare your testing team with too much integration(Git-> Jenkins->Kubernetes-> Docker), let them breathe with a single-click solution in place.
5. Visualize the ROI
At the end of the day, we all need to visualize what we spent our time and money on. I have seen organizations putting their money on resources(Leads /mid-senior level) only to get the data on their daily activities and progress, whereas this can be automated and visualized if you can come up with a data collector from various source and put it in a single platform. This invites a good amount of accuracy in the system, less bias in decision-making, and more transparency.
6. Predict Defect with AI ML
This has become quite popular these days, as AIML is probably the thing that everyone wants to learn and implement.
Before the developer announces the defect as a “Known Issue” and throws it in your bucket, try your history of data and save some time.
7. Make it as easy as a piece of cake
Keep working on your framework until it becomes too easy to be comprehensible by a layman. Do a workshop, check the standard, take feedback, improve it and repeat.
We do have the advantage to go behind the functional(manual) force but before we commit the automation on a bigger number of use-cases, the confidence metrics should be high with balanced attrition of resources. For a situation where the work is more and the budget and deadline are short, we do prefer a bunch of juniors to take care of the bigger chunk. We will inevitably end up spending more effort on knowledge transfer if the system is too complicated to get started with.
8. Either make your Developer do the testing or make developers out of your testing team, both ways you win! :)
With the rapid growth and surprising changes in techs over a short span of time testers have identified the risk of remaining a Tester and understood the importance of becoming a Developers in Test. They will come forward to push the barrier for their survival.
Developers on the other hand understand the rapid growth of automation and parity of It, they realize the importance of making a small effort and go the extra mile to save their organization a few bucks and taking ownership.
We should encourage this change both ways, in the end, we want the work done with minimum cost and maximum quality!
More to come on the list, will appreciate suggestions.
