Tuesday, August 18, 2009

Famous Five Why Analysis

In my last post, I described about “kaizen”, a continuous improvement process, but now the question is how we can introduce “kaizen”, in our lifes and partcularly in software development. Its always a great practice to review your work , either you are working in agile mode or some other other incremental approach, in some organizations, there are Post Project Report,or when we talk about agile , we have sprints and product owners often call for Sprint review meeting.

Five Why analysis is form of kaizen, it’s a technique of root cause anlaysis, it is a meeting of all stake holders , discussing critical issue faced during sprint or in project.

Lets suppose we faced a critical issue during sprint end while deploying our application to the production , the problem was that one of the key component was throwing exception on the server , but working fine in our environment with same code, team suffered a lot due to this issue ,suppose we solved the problem on priority basis, in order to complete our sprint, but now is the time to analyze about this issue using five why analysis

So


Why the component was not working in production environment?

The component was dependent upon the utility , whose files (Dll, EXE etc ) was not installed on the server.


Why it was not installed on the server?

During sever set up, team missed this utility, because it was not mentioned in the check list prepared for server set up.

Why it was not in the check list?

Because the respective code(utility) was not checked-in the code repository by the development team, and resource who preapred check-list, listed all componenets that were available on the Repository.

Why it was not checked in to the code repository?

Because developer did not push the utiliy to the code repository, and conducted unit tests on his machine,because he was not aware of that utility as well.

How testing team missed that dependency?

Because, the utility was already deployed to the QA server long time ago, so testing team was unaware of that utility.

So after these question,. We concluded that :


  • There should be properly reviewed installation checklist for server set up.
  • Before production, there should be a Pre-Production server, where Deployment team set envoirnment by taking with the code repository and executing checklist.

Its just an example, there are many scenarios, so just conducting a five why analysis at the end of each miles stones, we can reduce our gaps,if this practice continues, we can have our improvement process continue.

you can read more about five why form here

6 comments:

  1. Thanks for your encouraging feedback :)

    ReplyDelete
  2. Wow that's a great step-by-step issue solving mechanism.
    Truly agreed that it often happens when you are unaware of some utility already installed at your system and it reveals when the application goes into production.
    We at my current workplace used to deploy our final build at our own configured UAT server, its a machine with just basic configurations & utilities. Most of the time we get to know these kind a issues(one that you discussed) in this UAT server environment. And also we never forget to jot it down in our checklists if install any new utility required for a particular application.

    ReplyDelete
  3. Thanks fatima for your feedback:)

    We should be always evaluating ourselves, in every aspects of life, doing 5 why analysis technique helped me a lot.

    ReplyDelete
  4. Great to see you talk about the Root Cause Analysis approach and sharing a technique to practice it. This is so important.

    I believe as testers we're naturally thinking in this way when we try to assess why a bug has occurred. In our case we're perhaps looking more for a Near cause (analysis) and the developer might push to a Root cause so they can fix it.

    It's useful to be aware that RCA is a form of 'deductive' analysis. We have the observed issue and look to move from the general problem to the specific issue.

    The other side of this is Inductive Analysis where we postulate a specific issue has occurred and then work from the specific to the general. This is how we write those error trapping test cases. "If this bug existed how would I know - what test case I design to see if it's there?'

    This is Failure Modes Effects Analysis, the flip side of RCA.

    With RCA and FMEA a tester can apply inductive analysis at the test / test planning stage and deductive analysis as the bug triage / bug fix stage.

    A great topic that no tester I speak to ever talks about yet how important is it!

    Mark.

    ReplyDelete
  5. Thanks Mark,

    I really appreciate your great informative feedback

    ReplyDelete