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 http://toknow-11.wikispaces.com/Inductive+Reasoning

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.