Blog Details

Testing Parliament

Technical Debt in Test Automation

Before we begin diving into the topic, let us concede that test automation is a software development effort. Irrespective of new tools popping up claiming to give clients best return on investment on automation that does not require testers to know coding at all, at some point the need to twig that generated code will arise. Now coming back to the topic, a technical debt(a.k.a design debt or code debt)is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution or shortcuts now instead of using a better approach that requires time you don’t have. Many contractors that work for a client for a duration of six months are least likely to relate to what is a technical debt because when the sh@#$t hits the fan they are long gone. When the vendor asks the client if they need post-deployment support, the client does not see the need for it because the product will not undergo major changes any times soon. This dormant nightmare goes undetected for a few months after the test automation pack has been handed over to the client and the money has been paid.

The symptoms of hardcoded dates start to show. The scripts are failing because in the belly of the regression pack there is a date  that has elapsed and does not sit well with the pre-condition of the next script that depends on it. The symptom of loop conditions not exited when the condition is met is showing because after few months the data set is a bit larger. That linear search algorithm used instead of a binary search algorithm is showing its true colors. The scripts are annoyingly taking longer to execute. The symptoms of random number values with a small set range are showing, the scripts keep complaining that the system can’t save the record with the same unique number. All these issues point to scripts maintenance if you are lucky that the chickens came home to roost while your beloved contractor is still on the premises. If the contractors have left a long time ago then for their predecessors it means rework sometimes from scratch. If a proper hand over with documentation was done then all is not lost, else a new RFX will have to e drafted to get a new consulting company to redo the same scripts. One of the bottomless pits which guzzles money like nothing else is the cost of rework which is quite elusive to senior managers. The chart below illustrates the relationship between the costs that test automation life cycle goes through.

Technical Debt Cost

As shown in the chart above one of the primary factors that impede the testing team from realizing the benefits of test automation is technical debt. it chops most of the saved cost accumulated by the regression like a guillotine. There are several remedies that the team can put in place to reduce technical debt and maintenance of the test automation scripts. The options below are not exhaustive and other mechanisms can be employed like doing it right the first time.

  1. Code inspection
  2. Peer review
  3. Walkthrough
  4. Informal reviews
  5. Pair Programming

Most of the prior mentioned techniques to minimize technical debt are not fully understood or implemented properly from QA perspective. Code review process from development is seamless since there are tools to facilitate a sound review. Plugins can be installed in the IDE for the reviews. Many test automation professionals that I have interacted with has never been on a team that a formal review is conducted with processes, tools, reporting mechanism and Measuring  KPIs with regards to the value-add of the reviews. The primary objective of the review is to be able to measure the benefits the review brings because if you can’t measure it there is no point of tracking or doing it.

When it comes to reviews and technical debt, it reminds me of the words of  John Ruskin “when we build” from his  1849 book The Seven Lamps of Architecture. Please be aware that this quote has been modified to relate to software development, the original quote is much more poetic.

“When we Code, let us think that we Code forever. Let it not be for present delight nor for present use alone. Let it be such work as our predecessors will thank us for it “

The next topic we will dive deep into code review processes and tools in QA environment. The unit of measure for code quality.



Leave a Reply

Your email address will not be published.