Test analysis Graham et al Foundationf of Software Testing

1. TEST ANALYSIS:
IDENTIFYING TEST
CONDITIONS
Departement information
System
Faculty Science and
Technology
University of Islam Negri
Sultan Syarif Kasim Riau
Present by Ozi Saputra Graham et al Foundationf of Software T
http://sif.uin-
suska.ac.id/
http://www.uin-
suska.ac.id/
http://fst.uin-
suska.ac.id/

2. Present by Ozi Saputra Graham et al Foundationf of Software T
Test analysis is the process of looking at something that
can be used to derive test information. This basis for the
tests is called the 'test basis'. It could be a system
requirement, a technical specification, the code itself (for
structural testing), or a business process. Sometimes tests
can be based on an experienced user's knowledge of the
system, which may not be documented. The test basis
includes whatever the tests are based on. This was also
discussed in Chapter 1. From a testing perspective, we look
at the test basis in order to see what could be tested -
these are the test conditions. A test condition is simply
something that we could test. If we are looking to measure
coverage of code decisions (branches), then the test basis
would be the code itself, and the list of test conditions
would be the decision outcomes (True and False). If we
have a requirements specification, the table of contents can
be our initial list of test conditions.

3. Present by Ozi Saputra Graham et al Foundationf of Software T
A good way to understand requirements better is to try to define tests to
meet those requirements, as pointed out by [Hetzel, 1988].
For example, if we are testing a customer management and marketing
system for a mobile phone company, we might have test conditions that
are related to a marketing campaign, such as age of customer (pre-teen,
teenager, young adult, mature), gender, postcode or zip code, and
purchasing preference (pay- as-you-go or contract). A particular
advertising campaign could be aimed at male teenaged customers in the
mid-west of the USA on pay-as-you-go, for example.

4. Present by Ozi Saputra Graham et al Foundationf of Software T
Testing experts use different names to represent the basic
idea of 'a list of things that we could test'. For example,
Marick refers to 'test requirements' as things that should be
tested. Although it is not intended to imply that everything
must be tested, it is too easily interpreted in that way.
[Marick, 1994] In con- trast, Hutcheson talks about the 'test
inventory' as a list of things that could be tested
[Hutcheson, 2003]; Craig talks about 'test objectives' as
broad categories of things to test and 'test inventories' as
the actual list of things that need to be tested [Craig,
2002]. These authors are all referring to what the ISTQB
glossary calls a test condition.

5. Present by Ozi Saputra Graham et al Foundationf of Software T
When identifying test conditions, we want to 'throw the net wide' to identify
as many as we can, and then we will start being selective about which ones to
take forward to develop in more detail and combine into test cases. We could
call them 'test possibilities'.
In Chapter 1 we explained that testing everything is known as exhaustive
testing (defined as exercising every combination of inputs and preconditions)
and we demonstrated that this is an impractical goal. Therefore, as we cannot
test everything, we have to select a subset of all possible tests. In practice the
subset we select may be a very small subset and yet it has to have a high
proba- bility of finding most of the defects in a system. We need some
intelligent thought processes to guide our selection; test techniques (i.e. test
design tech- niques) are such thought processes.

6. Present by Ozi Saputra Graham et al Foundationf of Software T
A testing technique helps us select a good set of tests from the total
number of all possible tests for a given system. Different techniques offer
different ways of looking at the software under test, possibly challenging
assumptions made about it. Each technique provides a set of rules or
guidelines for the tester to follow in identifying test conditions and test
cases. Techniques are described in detail later in this chapter.

7. Present by Ozi Saputra Graham et al Foundationf of Software T
The test conditions that are chosen will depend on the test strategy or
detailed test approach. For example, they might be based on risk, models
of the system, likely failures, compliance requirements, expert advice or
heuristics. The word 'heuristic' comes from the same Greek root as
eureka, which means 'I find'. A heuristic is a way of directing your
attention, a common sense rule useful in solving a problem.
Test conditions should be able to be linked back to their sources in the
test basis - this is called traceability.
Traceability can be either horizontal through all the test documentation
for a given test level (e.g. system testing, from test conditions through
test cases to test scripts) or vertical through the layers of development
documentation (e.g. from requirements to components).

8. Present by Ozi Saputra Graham et al Foundationf of Software T
Why is traceability important? Consider these examples:
• The requirements for a given function or feature have changed. Some of the fields now have
different ranges that can be entered. Which tests were looking at those boundaries? They now need
to be changed. How many tests will actually be affected by this change in the requirements? These
questions can be answered easily if the requirements can easily be traced to the tests.
• A set of tests that has run OK in the past has started to have serious prob lems. What
functionality do these tests actually exercise? Traceability between the tests and the requirement
being tested enables the functions or features affected to be identified more easily.
• Before delivering a new release, we want to know whether or not we have tested all of the
specified requirements in the requirements specification. We have the list of the tests that have
passed - was every requirement tested?

9. Present by Ozi Saputra Graham et al Foundationf of Software T
Having identified a list of test conditions, it is important to prioritize
them, so that the most important test conditions are identified
(before a lot of time is spent in designing test cases based on them).
It is a good idea to try and think of twice as many test conditions as
you need - then you can throw away the less important ones, and
you will have a much better set of test conditions!
Note that spending some extra time now, while identifying test
conditions, doesn't take very long, as we are only listing things that
we could test. This is a good investment of our time - we don't want
to spend time implementing poor tests!

10. Present by Ozi Saputra Graham et al Foundationf of Software T
Test conditions can be identified for test data as well as for test
inputs and test outcomes, for example, different types of record,
different distribution of types of record within a file or database,
different sizes of records or fields in a record. The test data should
be designed to represent the most important types of data, i.e. the
most important data conditions.
Test conditions are documented in the IEEE 829 document called a
Test Design Specification, shown below. (This document could
have been called a Test Condition Specification, as the contents
referred to in the standard are actually test conditions.)

11. Present by Ozi Saputra
REFERENCE
Graham et al Foundationf of Software Testing