Thursday, 13 February 2014

Overview of basic analysis techniques

In order to write the test case sets the test group must perform analysis of available information and of the Test Item if it’s also available.

This analysis is intended to identify the overall Test Requirements that exist and break these down into the required test case sets.

Refer directly to the available information such as design and technical documentation and the test item itself.

Apply domain knowledge, previous experience with similar test items and understanding of customer needs to infer appropriate test cases.

Speak directly to developers, stakeholders and customers to elicit valid test cases.

In addition to the above approaches members of the test group will typically use:
  • Inductive analysis to identify test Cases before execution
  • Deductive analysis to add additional test cases once bugs are found

Image source

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

This may be validation not covering boundaries correctly or style tags not working on a particular browser. 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 test item.

With Deductive analysis we assume that erroneous behaviours and characteristics of features or functionality have been observed and we now need to work backwards to the bug which is the cause.

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 group assessing this will help development deliver fixes more efficiently.

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.


or visit

Read More

Liked this post?