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

As an engineer on the team, I see the discussion and short conversations on Technical Debt.  No matter what, there will be a Technical 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 Deterministic 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 repeatability to an extent.  Repeatability 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 system, 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 damaging the deterministic attribute which is seeded to a test.
• Picking and integrating such a deterministic 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.

The Odds and Otherside of Mentoring & Community Work

The space of mentoring and association is something not easy to understand in the begining days.  Especially when a mentor is not coming from a job having big designation and social media following.  I got hit by these waves.  Now, I know how to balance my swimming with these waves.  I'm swim smoothly without losing my energy and focus.  

I try to understand what could be going in the mind at the other end.

Here in this blog post, I'm sharing what I experience, and what I'm said by few who wants to pair up and practice.

The intention of this write up is to share what I look for in minimum and no intention of hurting or talking bad of anyone.

Do Not Disclose My Name and My Practice With You

I was approached by few fellow engineers from the software testing community.  After a few sessions of pair practicing and learning together, I was asked to not mention or take their name and talk about the practice's accomplisment in the community.  I respect and acknolwedge this ask.  But, then, I asked why so!  I did not see any appropriate reason or concern expressed for doing so.  I have not shared anything about our practices and so far accomplishment.

That said, I see these mentees and a few testing community had no concerns in tagging and getting associated with others in social media and in the community spaces.

The curious me, tried to uncover what could be the reason for this.  I learn, these are a first few reasons:

1. No big job title and role metnioned on my LinkedIn profile
2. Not having the major social media following
3. Not speaking often in conferences and not given an opportunity for not having a title or big company name in my LinkedIn profile
4. Not being a panelist in any conferences
5. Not being a panel member in  the discussion
6. Not being a AMA person in social media and community space
7. Not working in a organization which has brand name that bring crowd to conferences or to the one's benefits
8. Not getting into unneccessary discussion or space that highlights the exchange of words [not the thoughts]
9. For not taking the inequality gesture and treaments
10. For practicing deep
11. For offerring the assistance when it is not asked
• This thing, I stopped!
• I learned my lessons
12. Helping and assisting with no expectation in return
• When you do not asked for any returns, the value is not recongized
• The same people pay thousands elsewhere and say it did not help them
13. And, I'm too good and humble is what I see; this does not work in the longer run in any business
• And, being so makes me not practical

Today, I'm saying NO to --  who approach me, and, then ask me not to say with anyone in the community as it impacts them and their relationship with others. 

I'm asked to share and give my work and artefacts, but, do not want to step up for giving a mention or credit in public!  I don't get it how!

I'm saying NO for such learning association and mentorship connection for the last two years.  I see, this is the best that I can do.

The practice and learning need courage, and the openness to receive and give back. Without this, we cannot experience the learning, practice and growth.

It is not that I make it public by tagging and bragging.  I don't make enough time to brag by tagging unnecessarily.  I write it meaningfully when I see our accomplishment adds value and benefits to more people, and to the mentee and me.

The point is, who is seeking assisatance do not have enough courage to stand up and say, we are practicing.  But, the same people will associates every other corners tagging with credits to others.

So, where is the problem?  If it is associating together with me, I want to say no to those who see that problem.

This is not just with individuals.  I see the same with a few Software Testing Communities.  At the start of a day, it is a business for the software testing communities, today.  While I get a lot of learnings from the communities, such things need to be ignored, and I do it.  If we do not make a way to support and sustain the community bussiness, there will be no space to make meaningful and sensible noise and exchange the learning.  Today, I watch myself in how I contribute to certain testing communities.  Giving back to community is must when I get so much from community.

So, Why This Blog Post?

I want to share this blog post for first to whoever approach me for practicing together or a community work.

I do not want to partner and associate in a mentorship and community work, if a person and group is

• Lacking the courage
• Not wanting to give the due credits
• No mention for whatever we lose, learn and gain in the pair practice we do

If the receiver is not confident and happy about the learning, gain and loss we make together, then I want the person to make use of her/his time with other mentor and skilled engineer.  I refer them to other mentors [and skilled engineer].  That way, the person and group can feel proud of her/his learning and talk about it in public by mentioning the other mentor [and engineer] name. 

I'm not being paid or making money when I work with a mentee or for a software testing community.  I expect the recognition, mention and due credit to be put out in public when the mentee or a community makes a loss, benefit and gain.  I see this is a fair expectation!

I do not want to be used with no respect and keep asking for the same.  If I remain so, I will not set a better example to myself, my teams and to the fellow people in the community.

Be courteous to those who give you, while you do not know, what that person is going through.