Root Cause Analysis of Software Bugs using "5 Whys"?

Root Cause Analysis of Software Bugs using "5 Whys"

When solving problems, dig at the roots instead of just hacking at the leaves.

- Anthony J. D'Angelo                

"Problems" are the species who would love to return again and again ??, maybe in another form.

"Root Cause Analysis (RCA)" is used to find answers to?Why a problem has occurred.?It helps to figure out what happened, why and then prevent the chance of the same problem reoccurring.

What is?5 Whys?analysis?

Why + Why + Why + Why + Why = 5 why

This method is very simple. it aims to ask "Why" 5 (or more) times, in different ways until finding the real reason for the detected problem. This is effective when answers come from people who are involved with the process or the implementation.

Sakichi Toyoda, founder of "Toyota" developed this in 1930 to solve there day to day problems. Toyota has "Go and See" philosophy rather than guessing.

How we can use 5 whys to troubleshoot software bugs/incidents?

  1. Gather everyone including Dev, QA, BA, DevOps in the software delivery team.
  2. Understand the problem by discussing it with the team. Write the clear problem on an online or offline whiteboard.
  3. Ask the team "Why" problem occurred and based on the answers ask more whys.

Let's take an example

Problem:- Production Bug is found in an e-commerce web application (ex:- eBay) which submitted 'order number' displayed in UI is incorrect.

RCA (Development Team) - 5 Whys

  1. Why submitted 'order number' that is displayed in UI is incorrect? The 'order number' that came from?GET Order API endpoint response?is incorrect.
  2. Why 'order number' that came from GET Order API endpoint response is incorrect? The database has an 'order number' for the above record but API endpoint retrieves a different 'order number'.
  3. Why the 'order number' in the Database and API endpoint response is different??Because 'order number' generation logic is wrong.
  4. Why 'order number' generation logic is wrong? Order logic generated help of?order service API and another 3rd party API?endpoint but 3rd party API endpoint didn't send the correct 'order number'.
  5. Why 3rd party API didn't send the correct data? because we are calling the wrong endpoint of 3rd party API. we have to call the correct 3rd party API endpoint.

RCA (QA Team) - 5 Whys

  1. Why QA team couldn't identify this bug earlier? Test cases didn't have any failures in the test environment.
  2. Why did test cases didn't have failures on this bug? Only the results were compared between UI and API responses. API functionality has not been tested properly.
  3. Why API functionality has not been tested properly? QA automation team was responsible to automate?API functionality?and they didn't assert the API test properly.
  4. Why QA automation team didn't assert the API automation test properly? The automation team compared the POST Order request call response with GET order/id endpoint response but actual 'order number' created by a 3rd party API.
  5. Why Automation team compared the POST Order endpoint response only with GET order/id endpoint response? QA automation team made a mistake without asserting the 'order number' with 3rd party API response.

This 5 Whys method can be more useful when troubleshooting simple or moderate bugs but a good starting point to analyze critical issues as well. The technique usually starts with a technical issue but can point to a process failure.

**Important

  1. Sometimes this approach could take 6,7 iterations to identify the real root cause but don't ask too many Whys to make things complicated.
  2. Some issues can have more than 1 root cause and then this approach is more like a modal with different branches.

?? ?? ???Happy Reading??? ?? ??. Thank You for your time.

Nice write up. I use 5 whys to be emotional resilient and solve mental dilemmas. It's for everyone.

要查看或添加评论,请登录

Sithira Pathirana的更多文章

社区洞察

其他会员也浏览了