Friday, 23 November 2012

Near Cause and Root Cause Analysis

Let’s look back to the Deductive Analysis section and consider the issue of “…settlement amount on a transaction, given its base price and a fee that gets charged on top, is not adding up to what’s expected.”

Thinking this through as a worked example, how might we have found the issue? It appears we had some kind of trade or purchase to make, it looks like there’s a spot or base rate for the item but we have to pay a fee of some kind on top too. So if the item was £100 plus a 10% fee, we’d expect the total to be £110, just a simple one for ease of illustration.

Now the issue appears to be that our expected outcome of £110 wasn’t achieved, let’s say it came out at £120 when we ran an end of day report. What would you do? Well, you wouldn’t just report “settlement amount on a transaction is not adding up to what’s expected.” That isn’t Near or Root Cause analysis, it’s just issue reporting. It means the developer has to do all the investigation and as a Test Analyst you should be doing some.

So, we’d do some checking… check the figures that were input and make sure it was £100. OK, entry of the base figure is not an issue. Run different figures and see if they come out at amount + 10%, that’s OK too, it appears on our summary page as 10% fee and £110. At this point we could be ‘under’ the UI elements, nearer to the scripts that submit transactions, closer to the transaction or reporting database, etc.

This is a very simple example of Near Cause analysis and is the MINIMUM we should do. We’re nearer to the Root Cause and it will help the team member who has to fix it get to a fix more quickly. Let me say again, Near Cause analysis is the MINIMUM you should do when reporting any issue.

If we’re skilled enough or have appropriate access, etc. we might then look at underlying scripts and maybe take a look at the databases or other systems. We might now inject data straight into the database with a bit of SQL and run the transactions report. Let’s say when we do the report is now showing our £100 as a £120. Aha, so we’re getting warmer. We could realise that what’s presented on the UI is merely the output of a browser side JavaScript, but the actual final, chargeable amount is calculated by some clever server side code, as you’d expect due to security/hacking considerations if that was on the user facing side.

Now we have our Root Cause, script ABC is calculating the 10% fee twice. A developer can quickly crack open the script, correct some erroneous if-then or variable or whatever the cause was and deliver a fix.

In summary, Near Cause as a minimum, never ever just report an issue and leave it there. Root Cause if you have the time, understanding, etc. it doesn’t mean developers blindly correct what you suggest as Near or Root Cause, we always expect things to be peer reviewed. But in this way we cut down the find to fix time and get working software delivered. That’s what we’re here for right?

Mark.

Liked this post?


0 comments: