Anti-Patterns in Test Automation – Part 1

I have just finished jotting down all the Anti-Patterns that I have come across during my assignments and Best Practices that I have adopted to make my tests run on cloud and with distinguishing quality. And if I talk about all of them, I honestly don’t know how long this article is going to be. Therefore just like the title, I will, in this article, discuss habits that keep you away from keeping code hygiene and make your automation starve for love and respect. So lets’ start without any further ado.

Borrowing Existing Frameworks

Well, it’s not hidden from anyone. We have heard this before from someone that they have got a fantastic Test Automation framework for our new project from another team. With such suggestions, it’s easy to convince the team because we crave for being efficient, and it points to the definite time-saving scheme. Let me assure you, its a trap. It not only takes time for the team to understand the complete architecture but it also takes away the opportunity of collaboration, learning and to be creative.
Will we do the same for the Web Application or Backend services that are going to be your actual products? Every product has its needs, and our automation suite is not different from it. 

Absence of Cost Value Analysis

CVA, in our case, helps in determining how much testing is feasible. When we use it in automation projects, we intend to get the most productive areas to focus on automation. In my previous article, I gave an example of teams who thinks that 100% automation means we can automate anything/everything. Because of the lack of experience and short-sightedness on good testing practices, teams/organizations fail to get the most benefits out of it and compromise on quality and time invested. The product of this is an unmanageable automation suite that often needs a rework, takes time to automate tests and takes a longer time to execute.
In such cases, early feedback becomes a crucial factor. It leads us to continuous improvement at a measurable pace. And that’s the reason it gets essential to establish Cost and Value plan and segregate scenarios which are significant to business i.e. 

  • Priority 1 – High Value and Low Cost
  • Priority 2 – High Value and High Cost

Priority 1 cases or if I just say P1, are the case that takes less time to automate and delivers the purpose of validation whereas P2 cases take a bit higher time to automate in comparison to P1 cases. 

The key take away from this process is that it produces an intangible benefit that is measurable for decision and cost.

Longer Feedback Cycle

Brewing faster feedback is one of the essential steps for the test automation recipe because of the shorter execution cycle. But often team does not follow the plan of getting critical Business cases in their end to end testing suites which oppose the concept of faster execution. And ultimately the suite grows and take hours eventually increasing the overall time to deploy in a pipeline.
To counter bigger suites and manage them, well-experienced teams often try to divide big suites into multiple smaller suites with the help of Tags. And running tests in parallel helps in reducing the execution time exponentially.

Testing Data Vs Business Cases

In most of the occasion, Testers happens to consume significant time and effort to create and maintain test data for their suites. And if test data is vast, it grows despite their expectations because it needs to be maintained across environments if the testing in different environments is a requirement. Another unforeseen issue is stale data for your suite. In these case, test data needs to be prepared to keep the execution green for every iteration. Issues mentioned above cause the data to grow exponentially as the suite grows. And hence the team spend focused effort in managing the data instead of testing the business case/feature. 
To counter this anti-pattern, teams can plan and embed the actions as a check for their pipe like:

  • Cleaning up data before every execution
  • Maintaining data for every env separated from the suite or
  • Don’t use existing data; create it at runtime if it is possible.

In my current project, we are spinning a fresh environment for running our test suites in the pipe. This way we not only get a fresh DB but a clean environment too.

Record and Playback

Record and Playback feature has been in talks since I have started test automation. Everyone promotes it as if we can record our actions and play it repeatedly without any worries. As simple as it sounds. 
But shortly after using the RP tools, we all realize that it’s not going to work as we thought. It’s not the tool, but how we use it for automation. Currently, popular RP tools required hard-coded value for every action. To add more, when I record a test have to be extremely careful to keep the steps very precise so that I don’t have to dig the script and modify it to handle unwanted actions. Unfortunately, there is always some maintenance needed, and the whole suite becomes unreliable.
Although, to me, RP tools add essential value in learning how the identification of elements works in automation and sequencing of action and its translation to steps. And then that’s where it should remain.
This article can get long enough to lose interest if I explain everything at once. I intend to keep it elaborated yet crisp to explain the practice and concept I propose to share. The idea of doing so is to see a thoughtful progression of your understanding, and in return, your experience for everyone’s interests and learning. I hope I have justified it with this piece too. On that note, I hope to see you in the next article where I continue to address more anti-patterns.
Happy Testing.