Friday, 23 November 2012

Inductive and Deductive Analysis

More Advanced Analysis techniques

Once we have the basic analysis techniques of Reference, Inference and Conference understood we can look at some more advanced techniques. Many moons ago when I worked in manufacturing QA these two other techniques were my Katana and Wakizashi, slicing through the planning and root cause analysis problems. As often happens in a career with changes in focus, I forgot them for a while and then rediscovered them a few years back. These techniques are Inductive Analysis and Deductive Analysis.

These two are my favourites and to keep repeating the point, I’m guessing you already use them. If you’ve ever written any Test Cases or thought through why a bug might be occurring – you’ve already applied Inductive and Deductive Analysis, at least at a basic level. I consider these to be advanced techniques as they are relied on, albeit supported by some analysis tools, by industries where quality is paramount and any failure must be absolutely understood. Industries that use these techniques include gas and oil exploration, civil and military aerospace, the nuclear power industry, medical equipment manufacture and pharmaceuticals.

The test group will naturally apply Inductive and Deductive analysis as they carry out their testing activities. For example;

- When a bug is found, thought will be given to what other functionality may be affected and these areas of functionality will be checked
- When errors are observed that seem similar in nature connected paths of the user journey may be tested to see if these lead back to a single cause

In other words we could use:

- Inductive Analysis: to identify meaningful Test Cases, before any test execution takes place
- Deductive Analysis: to find Root Cause of issues and add additional Test Cases once bugs are found

For those who have followed the Testing Vs Checking debate, it should be noted that we’re not using these two techniques to check for requirements being implemented. I don’t believe the skills of a clever, experienced Test Analyst are best employed in marking the work of developers. In some ways I don’t feel this testing (really, checking) should even be done by professional testers, but that’s a topic for a post on UAT. Just assume for the sake of this post, your developers can code just fine and you need to find the tricky issues.

Inductive Analysis
When we apply Inductive Analysis we work from the perspective that a bug is present in the in the application under test, then try to evaluate how it would manifest itself in the form of erroneous behaviours and characteristics of the application’s features or functionality. One way to remember the purpose of Inductive Analysis is to remember that we move from the specific to the general.

At this point we could be applying Test Case Design Techniques and asking; if invalid data was input by the user, if a component state was not as expected and the user tried to carry out some action – how would we know? What would the failure look like? How would the error show itself to the user?

For those who are versed in manufacturing QA we’re also moving close to Failure Modes and Effects Analysis (FMEA), yet another interesting topic for another post…

With Inductive Analysis we move from the idea of a specific bug (a specific failure mode), that we agree could be present in the system and then ascertain its effect on, potentially numerous areas of, the application.

As I’m a fan of the Gherkin way of writing test conditions here’s a slightly construed example in that style:

GIVEN connectivity to the trade database has failed (our bug/failure mode[that may not be obvious])
WHEN the user submits their trade data for fulfilment (expected functionality of the system)
THEN the order will not be placed (failure effect [we can’t assume the user will know])
AND end of day reconciliation reports will show an outstanding order (definite ‘how’ we will know)

Remember, with Inductive Analysis you’re thinking about testing risks and designing a test case to cover that risk. Isn’t that more like testing than just checking requirements we’re implemented?

Deductive Analysis
With Deductive Analysis we assume that erroneous behaviours and characteristics of features or functionality have already been observed and reported. That is, we have a bug that’s been reported and we now need to work backwards to the Near Cause or Root Cause of the bug.

An example might be where style and layout on multiple pages of a website is not as expected, the specific cause perhaps being a bug in a CSS file. Perhaps a 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. In this way we attempt to move from the general issue that’s being observed to the specific Root Cause. It may be that a range of issues have a single root cause and the Test Analyst assessing this will help development deliver fixes more efficiently.

Deductive Analysis is most often used when testing is under way and bugs have been raised. Similarly, when the application is live and a customer reports a bug, applying Deductive Analysis is a natural approach for test and development staff to get to the Near Cause and Root Cause of the bug. We’ll cover that in the next post.


Liked this post?