What is root cause analysis and defered

can any one explain root cause analysis and defered with examples

Replies to This Discussion

Permalink Reply by vamshi on July 26, 2010 at 6:17pm

root cause analysis---Aims at identifying the root causes of problems or incidents.
Deferred--u might file an issue as Bug but management thinks of it to be an OK for this release but will consider in later versions....

Examples: U can think of such cases in ur environment now.

▶ Reply

Permalink Reply by phani kumar on July 26, 2010 at 6:34pm

Thanks vamshi

▶ Reply

Permalink Reply by Ajay Sanodaria on July 27, 2010 at 5:13pm

Hi Vamshi,

Have you faced ever this type of problem in your testing experience?

If possible please share...

▶ Reply

Permalink Reply by Sekhar on July 26, 2010 at 7:03pm

root cause analysis:- developer explains where the problem occured for eg: misunderstanding requirements or code changes or requirements gathering.
deferred:- raised bug but it won't effect on feature release so it can be fix in later in next releases.

▶ Reply

Permalink Reply by Mark Crowther on July 27, 2010 at 2:27am

Root Cause Analysis (RCA) is a deductive analysis technique applied when a bug has been found. RCA is mostly applied by those who need to fix the bugs, those who need to get to the specific root cause of the problem. As a tester we need to get the general near cause of the problem and report it in a bug report. Good on you if you get to the root cause :)

RCA can be considered a mirror of the inductive analysis technique called Failure Modes Effects Analysis (FMEA) that is applied before any bugs have been found. Testers apply FMEA when thinking about what bugs could be present and then writing a test case to try and catch them.

Mark.

▶ Reply

Permalink Reply by Mark Crowther on July 27, 2010 at 2:30am

Here's some text from my Test Practice training course on this topic

High Level Analysis Techniques
In addition to the above (Reference, Inference, Conference: see 'Lessons Learned in Software Testing') approaches the Test Consultant can also apply two other high level analysis techniques, namely:

• Inductive Analysis to identify Test Cases before execution.
• Deductive Analysis to add additional Test Cases once bugs are found.

The test group will naturally apply Inductive and Deductive analysis as they are testing. 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.

Inductive Analysis
When we apply Inductive Analysis we work from the perspective that a bug is present in the application under test and try to evaluate how it will manifest itself in the form of erroneous behaviours and characteristics of the applications features or functionality.

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?

We need to move from the specific bug that we assume or know is present and ascertain the broader scope of its effect on potentially numerous areas of the application.

Inductive Analysis is a powerful technique to apply when authoring Edge or Negative Test Cases, discussed next in Session 7.

Deductive Analysis
With Deductive Analysis we assume that erroneous behaviours and characteristics of features or functionality have already been observed, we have a bug that’s been reported and we now need to work backwards to the 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. In this way we attempt to move from the general to the specific. It may be that a range of issues have a single cause and the Test Consultant 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 root cause of the bug.