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.

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.

Do Adding Cores Improves The System's Performance?

Hardware and Programming Language

If I have no understanding of -- sysem's architecture, how the system is designed and implemented technically knowing its business purpose, then I cannot test for performance rationally and technically, 

In this context, the awareness and understanding of below is necessary and important.

1. The infrastructure where the system and its services are deployed and consumed
2. The hardware on which the system is deployed
• The understanding of the hardware along with its limitation
3. The hardware on which the service of the deployed system is consumed
• The limitation of consumer's hardware
4. Understanding the CPU and its Cores
• How we are programming the threads to exeucte on these Cores?
5. The programming language used to implement the system; this play a vital role
• Does it allow the threads to run on two and more different cores at a time?
• Or, does it confine the threads to run on one Core?
6. The way in which we have programmed the system for its instruction execution at a thread (subroutine) level
• How the threads are implemented and how it exeuctes on a CPU and its Cores?

I should be aware of above said information when building high performant system and testing for the performance of a system.

The value and benefits of these information are not just limited to performance testing alone. It also helps in testing for seucrity and functionality.  The awareness of these information will give you an edge in the testing for performance.

CPU Cores and Software System's Performance

I hear this often and especially during the businness seasons time:

"We will add more CPU with more cores. This will improve the exeuction time and improves the performance.  The business will not be impacted."

Does this make sense technically?  What's your thought on above statement as a Test Engineer testing the system for different quality criteria?

If I do not have awareness on information that I said above, I will not be in a position to test and advocate better for performance.

Do Cores Added Reduce the Exeuction Time?

By just adding more cores to a CPU, it does not always speed up a program's exeuction time.   

I learn, if a program which is designed to run on multiple cores have threads, that must run on one core, then this will be a limitation for the maximum speed [by reducing execution time] which we can achieve by adding more cores.

Also, the programming language used will have a role.  If the programming language uses Global Interpreter Lock (GIL), then it makes sure that a process created out of it can run only one instruction at a time, despite of the cores it is currently using.  That is, though a process created has access to multiple cores in a given time, the insturctions will be running on just one core.  Which means, the threads cannot run on multiple cores.  The instruction will be running on just one core and just one thread at any point in time.  Eventually, this leads to higher exeuction time for a process of program.

Should I say high exeuction time is a high performance and high performant system?  That is contextual!  What do you say?  What should a consumer of the service (business) say about this performance?

To summarize, adding multiple cores to a CPU, does not necessarily speed up the exeuction time for a program.  It is dependent on how we have designed and written the program and the programming language used.

To know more about GIL

• Global Interpreter Lock -- https://en.wikipedia.org/wiki/Global_interpreter_lock
• https://langdev.stackexchange.com/questions/1873/what-is-a-global-interpreter-lock-and-why-would-an-interpreter-have-it