Testing Debt -- It Exists and Hits Every Day in All Environments

As an engineer on the team, I see the discussion and short conversastion on Technical Debt.  No matter what, there will be a Technica Debt in the software system we build and deliver.

Likewise, when there is a Technical Debt, there will be a Testing Debt for sure.  Identifying and learning the magnitude and impact of the Testing Debt is part of my job.

My Understanding of Technical Debt

What is a Technical Debt?

• It is the cost of additional rework caused by choosing the quickest solution rather than the effective solution.
• Making decisions based on speed above all else is one factor that leads to the Technical Debt.
• Technical Debt has pros and cons.
• The unintended Technical Debt will not come to notice immediately or sooner.
• This is one of the challenges we have to deal with.
• Because intentional technical debt is what we are aware of from the decision made.
• The impact of unintended technical debt has to be managed by every team involved in the software development.

Starting With The Testing Debt

I don't know if the term Testing Debt exist in the industry!

I have been using the term "Testing Debt" for the last 9 years in my practice.

• I use this term to share and keep stakeholders informed about the rework which we have to do as a result of Technical Debt.  
• On reading, what is Technical Debt, can we relate to what is Testing Debt?
• Most times, the testability, automatability and observability characteristics of a system will be affected as a consequence of Technical Debt.
• Further, to compound the cascading effect, the Testing Debt will come in.
• One of the major impact due to the Testing Debt is the change in the Determinsitic capability seeded with a test
• Reworking on this deterministic capability is not simple and straight in all cases for the change introduced in the business operations, tech layer and infrastructure.

When I say, there is a Technical Debt arising from what we are doing and delivering, it also means, there is a Testing Debt that is created as a consequence.

• To speak in terms of engineering, the testing is part of technical activity.
• It looks funny to me when the one portrays the testing team as non-technical and label with terms.
• For example, manual, repeatable, repetitive, etc.  

It is a cycle and repeatbility to an extent.  Repetability is one part in the engineering cycle and process.

Do You Know Your Testing Debt?

To remind you and me, the testing is sampling!  How do you sample when you have a growing Technical Debt and Testing Debt?

I will share one of the common Testing Debt which we everyone of us will have and I assume so.  

The ask for in-sprint automation and automate everything.  Is this a fair ask and practical?  This is not a line to discuss here.  But, I will tell you how we testing team will be hit by the Testing Debt in delivering for this expectation set by business and stakeholders.

The Technical Debt leads to rework sooner or later in the engineering and it will lead to major rework in the Test Engineering.  Isn't it?  

Say you have worked to build the testing infrastructure, regression suite, automation suite and integrated with the pipeline.  Now, there is a rework and change in the system as a fix for few Technical Debts.  

• Does this effect your testing infrastructure, regression suite and automation suite that you have in place?  
• Do we have [or given] enough time and resources for Testing Team to work and fix this and keep the pipeline running seamlessly?
• This is not just about time and resources!
• For the change in tech stack and engineering of the system, the Test Engineering has to adapt to it and challenge it.
• If the Test Engineering does not challenge the engineering of the software sytem, we are not in a position to see the perspectives of risks and problems
• Eventually, we will not even be in place to learn what are the no-risk perspectives and aspects of the system
• How do I manage this so that I can turn around quickly to the context and keep the pipeline smooth?  
• This is a challenge to every Test Engineer who faces the effect of Technical Debt.

We Test Engineers witness and experience the Technical Debt which also includes Testing Debt in different forms and intensity.  

Wait!  As you read this blog post, did you try to think of the intended Testing Debt in your project?

What are the unintended Testing Debt and its impact?

• This is something not easy to identify and learn, while we can identify and learn the unintended Technical Debt to some extent.
• This will exist; it will impact and hit all the environments, everyday!

Testing Debt and Test Engineer

Note this, building a Test Engineering solutions to withstand the effects and changes from a Technical Debt is a skill.  It is possible.

• For this, the Technical Debt should not be damanaging the deterministic attribute which is seeded to a test.
• Picking and integrating such a determinsitic layer within the layer of testability, automatability and observability is a mark of a skilled Test Engineer and Test Engineering.

Technical Debt and Testing Debt are not the same.  But, the Testing Debt is the outcome of a Technical Debt and has a relation to it.  

Testing does not drive the change in how the system is implemented; or, I have not experienced it so far.  Wait!  The outcome of the testing can and has changed how the system is implemented.  These two sentences are not the same.

To end here, how do I manage myself with all these debts?  We are also in the job where we have to grow together by talking, negotiating and solving the debts that are the outcome of decisions from business and stakeholders.