What Is defect cascading in software testing?

Today, if you google ‘What is defect cascading’, I guess you will find this question among the top ~100-150 popular software testing interview questions. Wow! Since it has been a popular question for a long time, you might think there must be a solid reason. Right? Maybe or maybe not. Let’s explore!

Some popular answers

Since it is among the trendy questions, there are plenty of answers. I analyzed roughly the top fifty freely, readily available, and top-ranked answers. I found that 80% of those answers are framed using this theme,

Example 1:  “Defect cascading is when one Defect leads to the discovery of other defects. This can happen for a variety of reasons, but often it occurs because the original Defect was not fixed properly….”

Example 2: ‘..one defect leads to the occurrence of several other defects..’.

Example 3: ‘Defect cascading is a defect which is caused by another defect. In this one defect invokes the other defect in the application. When a defect is present in any stage but is not identified, it passes to other phases without getting noticed. This will result in increase in number of defects.’

Based on my experience, research, and common sense, all the above and other such answers based on such themes need an overhaul, and that’s my mission with this write-up.

My eligibility to address the question

I heard that a lot can happen when a butterfly sneezes, and everything seems connected in this world. Also, we all encounter or get affected by cascading(s) in different walks of our personal and professional lives. Hence, because of the following key reasons, I wanted to write beyond what was already published and surpass the boundaries of the interview-cracking mindset.

1. In my day-to-day work, I often encounter a bug-cascading phenomenon; whether we talk about it explicitly using the same terminology or not, we usually face it.
2. I know something about bugs, bug clusters, cascading effects, masked bugs, bad tests, linked bugs, bugs that may never be found, mean time to find (MTTF), mean time to resolve (MTTR), root cause analysis, and five why’s to name a few.

For example, let’s take one example of a situation that arose from identifying bug clusters, one of the seven software testing principles. 

1. Clustering of serious bugs often leads to worries in the minds of business teams and management. 
2. Fixing such bugs and clusters leads to unwanted delays in completing the feature development.
3. Late development may lead to unhappy customers due to delayed and often buggy deployments. 
4. Additionally, as a byproduct, a relatively high cost of fixing and resultant degraded regression is sometimes inevitable. 

Do you see a pattern emerging? Do you think it seems to be a cascading effect?

Is There A Problem With The Interview-size Explanations?

Yes and No!

No. As long as your objective is memorizing the answer(s) with a limited set of examples to crack another old-fashioned software testing (manual?) interview.

Yes. Because such answers serve the purpose of cracking interviews while the need is to go deeper, find meaningfulness, and question the status quo.

As aforementioned, It is evident that ‘Defect Cascading’ has been among the top 50, 75, 100, and … up to 150 software testing-related interview questions, even in 2023! I came across several blogs (personal and organizational), white papers, YouTube, and Instagram videos explaining this concept. 

While I appreciate the authors’ attempts to express their point of view, 90% of the explanations of Defect Cascading need an advancement immediately! 

The much required nourishment

At a bare minimum level, the existing writings need nourishment regarding references, discussions, examples, and case studies that give my software testing friends some good insights into the following.

1. Context.
2. System(s).
3. Interaction and Interdependencies. 
4. Events.
5. Effects, Failures, and Adverse Impacts.

Another significant challenge is that most such writings focus too much on defects in unfixed or poorly resolved states or defects at the code level. Some of those writings talked about ‘roots’ and ‘causal analysis’ but only superficially. 

I was thinking, where is the depth? Where is experiential learning?

My Mission

My mission is to help you to think deeper and broader about ‘Defect Cascading’ by 

• Uncovering foundational elements.
• Bringing depth by cross-pollinating knowledge from other fields.
• Connecting the …
• Enabling you to frame further questions on my understanding and explanation.

Are we the Curious One(s)?

Now, I need to tell you two important things

1. Despite my experience level, academically and practically, I found it very interesting to concatenate the two strings, ‘Defect’ and ‘Cascading,’ in the given order and come up with something valuable and practical beyond answering the question for interview purposes.
2. Defect Cascading was interesting to explore beyond what I thought I knew because, during my research, I encountered faults and cascading effects related to case studies across various fields, including Transportation, Health, Wars, and Disaster management. 

In the coming sections, I will focus on explaining Defects, Cascading, Cascading Failures, and Cascading Impacts by going beyond traditionally popular definitions and limited examples on the internet.

So, a warm welcome to read this post if, 

• If you are brand new to the world of ‘Defect Cascading,.’
• You have faced this question of ‘Defect Cascading’ in a context not only limited to clearing the ‘Interview.’
• You face bugs, requirements, defects related, or any other kind of cascading effects and impacts in your day-to-day software product testing work.

I hope that after reading this post,  

• You should have insights to construct practical and valuable answer(s) to the question ‘What is Defect Cascading?’.
• You can start appreciating direct or indirect examples from the actual / software development world to expand your knowledge on cascading.

I leave you, the curious and enthusiastic testers, with the homework of validating, invalidating, or optimizing this method of understanding ‘Defect Cascading.’ 

Let’s Ask Questions to Unlearn & Relearn!

As I mentioned before that most of the answers I found are around this theme, 

‘..one defect leads to the occurrence of several other defects..’. 

Additionally, those answers provide examples of calculations, resultant erroneous data, resultant wrong reports, and something similar. Some are at a superficial level, and some go into little depth, too. 

I felt constrained while reading existing explanations. I felt an immediate need for more generalization and common sense.

Hence, I devised my thinking model to trigger thinking in your mind about this concept in the following way!

I wanted more and I borrowed ideas from different yet closely related fields. I studied diverse examples and case studies from those fields to eliminate language stagnation in the previously mentioned explanations.

WHAT do we know?

I observed a pattern in explaining Defect and Cascading. 

It is worth mentioning that, in every single writing on this topic that I went through, a Defect is defined as ‘Software’s actual behaviour is inconsistent with expected one.’ While this view is a good starting point, we can still do better.

Cascading is also influenced by the point of view of ’cause and effect’, ‘occurrences,’ and the seemingly necessary presence of an ‘unidentified defect’ or ‘unresolved defect’ or ‘poorly resolved defect’. Again, this can be a good starting point of view, and we can think deeper and broader.

The above two observations proved decent motivators for me to dig deeper and progressively think, write, and rewrite.

WHY do we need to know a little better?

The ‘WHY’ goes back to how software testers need to pay more attention to the value of this concept. Almost 75% of the existing individual tester’s blog posts, LinkedIn articles, YouTube videos, Insta posts, and testing companies’ blog posts convey the aforementioned popular view about Defect cascading from ‘answering an interview question’ standpoint. 

That’s it! When I started thinking about it, I had four questions: w.r.t. Defect Cascading.

1. What is the practicality and usefulness in knowing Defect Cascading? 
2. Why does it seem limited to Interview questions only? 
3. Why is it not included or proposed as one of the Software Testing principles?
4. Why isn’t a progressive view available in the software testing context?

The above four questions further motivated me to share my views through this post.

WHAT needs our attention?

I emphasize thinking in terms of these seven dimensions. 

1. Context
2. System
3. Interdependencies and Interactions,
4. Unexposed sensitivities
5. Triggering Events
6. Effects (usually failure propagation)
7. Impacts

WHEN and WHERE can we use the knowledge?

In the day-to-day testing context, 

The concept (or deemed principle?) and the idea(s) behind coining ‘Defect Cascading’ primarily apply to how we think about our world, the models we create, events that take place, and propagating effects and consequences.

This knowledge is applicable even before starting a dedicated testing effort because the cascading’s trigger point could be anywhere, and vulnerabilities (sensitives) could be of any type and from anyone. They may remain unexposed or get exposed at any time and in no time. 

WHAT do we need to know Next?

That’s the essence of the rest of the article, and you will read it in further lines.

Revisiting Foundational Elements

Defective Piece?

The first time I heard the word Defect was in my childhood. It was in the context of a newly purchased electrical item that didn’t work. We declared it a ‘defective piece,’ and replaced it with a new one. The other words I often heard were ‘Faulty’ or ‘Fault.’

Funnily, from the word Defective, I quickly recall a famous dialog by Saif Ali Khan (A Bollywood movie actor), which reads, “…Mai Defective piece hoon, phat se theek ho jaoonga…” (The English translation is – I am a defective piece and shall be back to normal amazingly quickly!) Ref: https://www.instagram.com/p/CyPh8hPPbmp/

In the age of AI and self-healing (something), I hope it becomes valid with software defects, provided we know what a defect is! 

Software Defect?

So, while I knew something about Defects and Faults, it was until my graduation back in 2005 that I first heard about ‘Bugs.’ I had never heard about bugs so predominantly before, and that too in software engineering books. 

Even today, I am unsure if it is for good or bad, especially in the context of the existing posts on ‘Defect Cascading’; the word Defect is interchangeably used to describe a Bug.

But thanks to my biases and education, I prefer to define a Defect differently from a Bug. I tend to give more weightage, emotional attachment, and attention to a Defect rather than a Bug. You should download and read this or this to understand what I am trying to convey.

If you decide not to read these references, please use Defect and Serious Bug “interchangeably” in day-to-day testing conversations.

So, in his seminal paper titled as 

‘Bug Advocacy – How to Win Friends, Influence programmers and SToMp BUGs’, Dr. Cem Kaner talks about Defect as follows.

So, in this post, I will not use Bugs and Defects interchangeably. I would be cautious here not to use Defects as an exact mirror image of Bugs.

I also wanted to explore if a defect is an ordinary defect causing localized problems v/s not-so-ordinary defect that can cause a series of cascading effects in the software product and its operating environment. 

Cascading?

I also avoid visualizing cascading as a Domino Toppling or a simple cause/effect chain reaction, though both could work well as a starting point.

I will also not pick the small waterfall or group of small waterfalls models to define cascading. 

In the context of this post and what resonates with my point of view, I cherry-picked the following definition of cascading.

Additionally, I am more impressed with the point of view of defining cascading.

‘A cascade of perfect movements, with hundreds of brilliantly calibrated actions, coursed through the mechanical man.’

If you are with me so far, Thanks because after giving you a gist of my current thinking about Defect and Cascading, it’s time for me to tell you a story, show you a practically comprehensible model, and reference a way of thinking.

Story of a Major Breakdown

Now that you have some idea or a space to rethink Defects and Cascading, I tell you a story. 

India (That is Bharat) or Bharat (That is India) is the world’s third-largest producer and consumer of electricity after the United States and China.

India has faced two major blackouts. One in 2001 and another one in 2012. I remember those last two days of July 2012 when a power failure cascaded through the northern grid. Over 300 million people, about 25% of India’s population, were without power for two consecutive days. 

Delhi Metro, Indian Railways, Water Treatment Plants, Hospitals, Traffic Signals, Airports, Businesses, and so on were poorly affected due to this blackout.

Per Wikipedia (at the time of drafting this post), A senior director for an Indian power company described the outage as “a fairly large breakdown that exposed major technical faults in India’s grid system. Something went terribly wrong which caused the backup safety systems to fail.

Notice the words: Breakdown, exposed, technical faults, something went terribly wrong, caused, and systems to fail.

The above description does not mention the word ‘Defect.’ Still, it touches upon ‘Fault’ and yet a classic example of ‘some kind of defectivity somewhere.’

Note: If you appreciate learning and understanding the difference between a bug, Defect, issue, failure, fault(error), symptom, and problem, and if you want to build up a solid and helpful vocabulary for different testing contexts, the paper and the course shall help you. A glimpse is below.

Building Vocabulary

A Cascading Failure

Now, for ~20 seconds, look carefully at the (.gif) image below and appreciate how the designer created an animation modeling a cascading failure.

At the beginning (relative to the time of accessing this post and reaching here), what you should see is…

1. A normally running network
2. Starts suffering from node failures
3. It then tries to re-balance itself
4. Followed by stability attempts on node repairs. 

But at a certain point, the network is distressed so severely that the entire network fails despite intermediate repairs of the failed nodes.

Again, taking word to word explanation of the phenomenon from Wikipedia, 

A cascading failure is a failure in a system of interconnected parts in which the failure of one or few parts leads to the failure of other parts, growing progressively as a result of positive feedback. This can occur when a single part fails, increasing the probability that other portions of the system fail.

Cascading Effects

An example from Design

So far, I have given you thinking opportunities around Defects, Cascading Effects, and Failures! Now, let’s look at the following statement copied and pasted as it is from a blog post.

As I read the statement, 

The effects of good design cascade into the users lives, and into the lives of the people they interact with and each small improvement to design creates a cascading impact on the users.

Another example from Performance Testing

Those who belong to performance and load testing know well that there is never a single point of slowness when it comes to products failing to meet the speed and user experience-related technical SLAs and NFRs. That ultimately deprives users of a highly satisfying user experience. See some cascading?

Most performance issues are due to a cascading effect, in the sense that either…

1. The performance goals or testing objectives were not well defined OR 
2. Technical specifications or requirements are not well specified OR 
3. The backend needs to serve better. OR 
4. Middleware becomes bottleneck OR 
5. The front end is problematic, OR 
6. Something went wrong at the user’s end. 

That is why a carefully crafted test strategy that appropriately, timely, and sufficiently covers the front end, middleware, and backend is paramount. 

Connecting the dots

It clicked to me that it shouldn’t be relatively tricky to say…

1. The immediate or long pending effects of not-so-ordinary defects in the product or its environment may cascade into the users’ lives and those they interact with. 
2. When triggered, each minor vulnerability, not necessarily faults or defects or shortcomings here and there, including the operating environment, can create a cascading lousy impact on the users.

If I made the above statement a bit complex, here is a simpler version.

So, what do you think if you are with me so far? Take a pause, think, and let me know using comments if you see a defect in my thinking causing cascading effects or if you see multiple defects cascading first and then creating effects.

Aren’t you also thinking it is purely not about Defects Cascading but Cascading Failures and Cascading harmful Impacts on users, systems, and businesses caused by an Event?

Defect(s) responsible for cascading failure(s)

Proposal

I propose we carefully define a defect, and understand how some not-so-ordinary defects can create a cascading (rippling) effect, resulting in cascading failure(s) in software products and hurting customers, users, and businesses. 

I would further propose that we should move away from the not-so-insightful definitions of “Defect Cascading,” which provides zero or very little supporting information about the following

1. Context.
2. Systems and its components.
3. Interdependencies and Complex Interactions within the system.
4. Unresolved, unexposed, and unstressed vulnerabilities.
5. Triggering events.
6. Positive Feedback.
7. Cause and Effect (possibly).
8. Localization.
9. Amplification.
10. Users (especially badly or severely impacted users).

Reference points

1. Memory Leak
2. Network Failure
3. Climate Change