particularly worth applying. For example, DO178-B [RTCA] requires structural

may count different things as statements, but the basic principle is the same however
they are counted.) A statement may be on a single line, or it may be spread over
several lines. One line may contain more than one statement, just one statement, or
only part of a statement. Some statements can contain other statements inside them.
In code sample 4.2, we have two read statements, one assignment statement, and
then one IF statement on three lines, but the IF statement contains another statement
(print) as part of it.
1 READ A
2 READ B
3 C = A + 2*B
4 IF C > 50 THEN
5
PRINT 'Large C'
6 ENDIF
Code sample 4.2
Although it isn
’t completely correct, we have numbered each line and will regard
each line as a statement. (Some tools may group statements that would always be
executed together in a basic block which is regarded as a single statement.) How-
ever, we will just use numbered lines to illustrate the principle of coverage of
statements (lines). Let
’s analyze the coverage of a set of tests on our six-statement
program:
TEST SET 1
Test 1 1
: A ¼ 2; B ¼ 3
Test 1 2
: A ¼ 0; B ¼ 25
Test 1 3
: A ¼ 47; B ¼ 1
Which statements have we covered?
l
In Test 1_1, the value of C will be 8, so we will cover the statements on lines 1 to
4 and line 6.
l
In Test 1_2, the value of C will be 50, so we will cover exactly the same
statements as Test 1_1.
l
In Test 1_3, the value of C will be 49, so again we will cover the same
statements.
Since we have covered five out of six statements, we have 83% statement
coverage (with three tests). What test would we need in order to cover statement 5,
the one statement that we haven
’t exercised yet? How about this one:
Test 1 4
: A ¼ 20; B ¼ 25
This time the value of C is 70, so we will print
‘Large C’ and we will have
exercised all six of the statements, so now statement coverage = 100%. Notice that
we measured coverage first, and then designed a test to cover the statement that we
had not yet covered.
Note that Test 1_4 on its own is more effective (towards our goal of achieving
100% statement coverage) than the first three tests together. Just taking Test 1_4 on
its own is also more efficient than the set of four tests, since it has used only one test
instead of four. Being more effective and more efficient is the mark of a good test
technique.
Section 4 Structure-Based or White-Box Techniques 103

4.4.3 Decision coverage and decision testing
A decision is an IF statement, a loop control statement (e.g. DO
–WHILE or
REPEAT
–UNTIL), or a CASE statement, where there are two or more possible
exits or outcomes from the statement. With an IF statement, the exit can either be
TRUE or FALSE, depending on the value of the logical condition that comes after
IF. With a loop control statement, the outcome is either to perform the code within
the loop or not
– again a True or False exit. Decision coverage is calculated by:
Decision coverage
¼
Number of decision outcomes exercised
Total number of decision outcomes
 100%
What feels like reasonably thorough functional testing may achieve only 40% to
60% decision coverage. Typical ad hoc testing may cover only 20% of the deci-
sions, leaving 80% of the possible outcomes untested. Even if your testing seems
reasonably thorough from a functional or specification-based perspective, you may
have only covered two-thirds or three-quarters of the decisions. Decision coverage is
stronger than statement coverage. It
‘subsumes’ statement coverage – this means
that 100% decision coverage always guarantees 100% statement coverage. Any
stronger coverage measure may require more test cases to achieve 100% coverage.
For example, consider code sample 4.1 again.
We saw earlier that just one test case was required to achieve 100% statement
coverage. However, decision coverage requires each decision to have had both a
True and False outcome. Therefore, to achieve 100% decision coverage, a second
test case is necessary where A is less than or equal to B. This will ensure that the
decision statement
‘IF A > B’ has a False outcome. So one test is sufficient for
100% statement coverage, but two tests are needed for 100% decision coverage.
Note that 100% decision coverage guarantees 100% statement coverage, but not the
other way around!
1 READ A
2 READ B
3 C = A – 2*B
4 IF C < 0 THEN
5
PRINT 'C negative'
6 ENDIF
Code sample 4.3
Let
’s suppose that we already have the following test, which gives us 100%
statement coverage for code sample 4.3.
TEST SET 2
Test 2 1
: A ¼ 20; B ¼ 15
Which decision outcomes have we exercised with our test? The value of C is
–10,
so the condition
‘C < 0’ is True, so we will print ‘C negative’ and we have exercised
the True outcome from that decision statement. But we have not exercised the
decision outcome of False. What other test would we need to exercise the False
outcome and to achieve 100% decision coverage?
Before we answer that question, let
’s have a look at another way to represent
this code. Sometimes the decision structure is easier to see in a control flow diagram
(see Figure 4.4).
Decision coverage The
percentage of decision
outcomes that have been
exercised by a test suite.
100% decision coverage
implies both 100%
branch coverage and
100% statement
coverage.
104
Chapter 4 Test design techniques

The dotted line shows where Test 2_1 has gone and clearly shows that we
haven
’t yet had a test that takes the False exit from the IF statement.
Let
’s modify our existing test set by adding another test:
TEST SET 2
Test 2 1
: A ¼ 20; B ¼ 15
Test 2 2
: A ¼ 10; B ¼ 2
This now covers both of the decision outcomes, True (with Test 2_1) and False
(with Test 2_2). If we were to draw the path taken by Test 2_2, it would be a straight
line from the read statement down the False exit and through the ENDIF. Note that
we could have chosen other numbers to achieve either the True or False outcomes.
As a final note on decision testing, let us point out that two slightly different
terms are used in both the ISTQB Syllabus and Glossary. One term is
‘decision
testing
’ and the other is ‘branch testing’. Some people distinguish between the
terms, saying that branches originate from decision points in the code and show
the transfer of control to different locations in the code. Therefore, some would say
that branch testing focuses on the execution of the branches, the distinct segments of
code, while decision testing focuses on the outcome of the decisions. Since the
outcome of the decisions determines the branches taken, this strikes us as a distinc-
tion without a practical difference.
4.4.4 Other structure-based techniques
There are other structure-based techniques that can be used to achieve testing to
different degrees of thoroughness. Some techniques are stronger (require more tests
to achieve 100% coverage and therefore, have a greater chance of detecting defects)
and others are weaker.
For example, branch coverage is closely related to decision coverage and at
100% coverage they give exactly the same results. Decision coverage measures the
coverage of conditional branches; branch coverage measures the coverage of both
conditional and unconditional branches. The Syllabus uses decision coverage, as it
Read
TRUE
FALSE
ENDIF
Print
C < 0
F I G U R E 4 . 4
Control flow diagram for code sample 4.3
Branch coverage The
percentage of branches
that have been exercised
by a test suite. 100%
branch coverage implies
both 100% decision
coverage and 100%
statement coverage.
Section 4 Structure-Based or White-Box Techniques 105

is the source of the branches. Some coverage measurement tools may talk about
branch coverage when they actually mean decision coverage, or vice versa.
Other control-flow code-coverage measures include linear code sequence and
jump (LCSAJ) coverage, condition coverage, multiple condition coverage (also
known as condition combination coverage) and condition determination coverage
(also known as multiple condition decision coverage or modified condition decision
coverage, MCDC). This technique requires the coverage of all conditions that can
affect or determine the decision outcome.
Another popular, but often misunderstood, code-coverage measure is path cover-
age. Sometimes any structure-based technique is called
‘path testing’ [Patton 2001].
However, strictly speaking, for any code that contains a loop, path coverage is
impossible since a path that travels round the loop three times is different from the
path that travels round the same loop four times. This is true even if the rest of the
paths are identical. So if it is possible to travel round the loop an unlimited number
of times then there are an unlimited number of paths through that piece of code. For
this reason it is more correct to talk about
‘independent path segment coverage’
though the shorter term
‘path coverage’ is frequently used.
The idea of coverage, the number of things that have been tested compared to the
total number of things, can be applied not just to code structure, but also at
integration and system level, although the things being counted would be different.
For example an integration test may measure the coverage of modules called,
components integrated or classes exercised. Tool support is generally better for
component coverage than integration or system coverage.
Structure-based measures and related test design techniques are described in
[BS7925-2]. Structure-based techniques are also discussed in [Copeland 2003] and
[Myers 1979]. A good description of the graph theory behind structural testing can
be found in [Jorgensen 1995] and [Hetzel 1988] also shows a structural approach.
[Pol et al. 2001] describes a structure-based approach called an algorithm test.
4 . 5
E X P E R I E N C E - B A S E D T E C H N I Q U E S
SYLLABUS LEARNING OBJECTIVES FOR 4.5
EXPERIENCE-BASED TECH NIQUES (K2)
LO-4.5.1 Recall reasons for writing test cases based on intuition,
experience and knowledge about common defects. (K1)
LO-4.5.2 Compare experience-based techniques with specification-
based testing techniques. (K2)
In this section we will look at two experience-based techniques, why and when they
are useful, and how they fit with specification-based techniques.
Although it is true that testing should be rigorous, thorough and systematic, this
is not all there is to testing. There is a definite role for non-systematic techniques,
i.e. tests based on a person
’s knowledge, experience, imagination and intuition. The
reason is that some defects are hard to find using more systematic approaches, so a
good
‘bug hunter’ can be very creative at finding those elusive defects.
106
Chapter 4 Test design techniques

In this section, look for the definitions of the glossary terms attack, exploratory
testing and fault attack.
4.5.1 Error guessing and fault attacks
Error guessing is a technique that should always be used as a complement to other
more formal techniques. The success of error guessing is very much dependent on
the skill of the tester, as good testers know where the defects are most likely to lurk.
Some people seem to be naturally good at testing and others are good testers
because they have a lot of experience either as a tester or working with a particular
system and so are able to pin-point its weaknesses. This is why an error-guessing
approach, used after more formal techniques have been applied to some extent, can
be very effective. In using more formal techniques, the tester is likely to gain a better
understanding of the system, what it does and how it works. With this better
understanding, he or she is likely to be better at guessing ways in which the system
may not work properly.
There are no rules for error guessing. The tester is encouraged to think of
situations in which the software may not be able to cope. Typical conditions to
try include division by zero, blank (or no) input, empty files and the wrong kind of
data (e.g. alphabetic characters where numeric are required). If anyone ever says of a
system or the environment in which it is to operate
‘That could never happen’, it
might be a good idea to test that condition, as such assumptions about what will and
will not happen in the live environment are often the cause of failures. A structured
approach to the error-guessing technique is to list possible defects or failures and to
design tests that attempt to produce them. These defect and failure lists can be built
based on the tester
’s own experience or that of other people, available defect and
failure data, and from common knowledge about why software fails. This way of
trying to force specific types of fault to occur is called an
‘attack’ or ‘fault attack’.
See [Whittaker 2003].
4.5.2 Exploratory testing
Exploratory testing is a hands-on approach in which testers are involved in
minimum planning and maximum test execution. The planning involves the creation
of a test charter, a short declaration of the scope of a short (1 to 2 hour) time-boxed
test effort, the objectives and possible approaches to be used.
The test design and test execution activities are performed in parallel typically
without formally documenting the test conditions, test cases or test scripts. This does
not mean that other, more formal testing techniques will not be used. For example,
the tester may decide to use boundary value analysis but will think through and test
the most important boundary values without necessarily writing them down. Some
notes will be written during the exploratory-testing session, so that a report can be
produced afterwards.
Test logging is undertaken as test execution is performed, documenting the key
aspects of what is tested, any defects found and any thoughts about possible further
testing. A key aspect of exploratory testing is learning: learning by the tester about
the software, its use, its strengths and its weaknesses. As its name implies, explora-
tory testing is about exploring, finding out about the software, what it does, what it
doesn
’t do, what works and what doesn’t work. The tester is constantly making
decisions about what to test next and where to spend the (limited) time.
Fault attack
(attack) Directed and
focused attempt to
evaluate the quality,
especially reliability, of a
test object by attempting
to force specific failures
to occur.
Exploratory testing An
informal test design
technique where the
tester actively controls
the design of the tests as
those tests are performed
and uses information
gained while testing to
design new and better
tests.
Section 5 Experience-Based Techniques 107

This is an approach that is most useful when there are no or poor specifications
and when time is severely limited. It can also serve to complement other, more
formal testing, helping to establish greater confidence in the software. In this way,
exploratory testing can be used as a check on the formal test process by helping to
ensure that the most serious defects have been found.
Exploratory testing is described in [Kaner 2002] and [Copeland 2003]. Other
ways of testing in an exploratory way (
‘attacks’) are described by [Whittaker 2003].
4 . 6
C H O O S I N G T E S T T E C H N I Q U E S
SYLLABUS LEARNING OBJECTIVES FOR 4.6 CHOOSING
TEST TECHNIQUES (K2)
LO-4.6.1 Classify test design techniques according to their fitness to
a given context, for the test basis, respective models and
software characteristics. (K2)
In this final section we will look at the factors that go into the decision about which
techniques to use when. There are no Syllabus terms for this section.
Which technique is best? This is the wrong question! Each technique is good for
certain things, and not as good for other things. For example, one of the benefits of
structure-based techniques is that they can find things in the code that aren
’t
supposed to be there, such as
‘Trojan horses’ or other malicious code. However,
if there are parts of the specification that are missing from the code, specification-
based techniques can find that
– structure-based techniques can only test what is
there. If there are things missing from the specification and from the code, then only
experience-based techniques would find them. Each individual technique is aimed at
particular types of defect as well. For example, state transition testing is unlikely to
find boundary defects.
The choice of which test techniques to use depends on a number of factors,
including the type of system, regulatory standards, customer or contractual require-
ments, level of risk, type of risk, test objective, documentation available, knowledge
of the testers, time and budget, development life cycle, use case models and
previous experience of types of defects found.
Some techniques are more applicable to certain situations and test levels; others
are applicable to all test levels.
This chapter has covered the most popular and commonly used software testing
techniques. There are many others that fall outside the scope of the Syllabus that this
book is based on. With so many testing techniques to choose from how are testers to
decide which ones to use?
Perhaps the single most important thing to understand is that the best testing
technique is no single testing technique. Because each testing technique is good at
finding one specific class of defect, using just one technique will help ensure that
many (perhaps most but not all) defects of that particular class are found. Unfortu-
nately, it may also help to ensure that many defects of other classes are missed!
Using a variety of techniques will therefore help ensure that a variety of defects are
found, resulting in more effective testing.
108
Chapter 4 Test design techniques

So how can we choose the most appropriate testing techniques to use? The
decision will be based on a number of factors, both internal and external.
The internal factors that influence the decision about which technique to use are:
l
Models used
– Since testing techniques are based on models, the models
available (i.e. developed and used during the specification, design and
implementation of the system) will to some extent govern which testing
techniques can be used. For example, if the specification contains a state
transition diagram, state transition testing would be a good technique to use.
l
Tester knowledge/experience
– How much testers know about the system and
about testing techniques will clearly influence their choice of testing techniques.
This knowledge will in itself be influenced by their experience of testing and of
the system under test.
l
Likely defects
– Knowledge of the likely defects will be very helpful in choosing
testing techniques (since each technique is good at finding a particular type
of defect). This knowledge could be gained through experience of testing a
previous version of the system and previous levels of testing on the current
version.
l
Test objective
– If the test objective is simply to gain confidence that the software
will cope with typical operational tasks then use cases would be a sensible
approach. If the objective is for very thorough testing then more rigorous and
detailed techniques (including structure-based techniques) should be chosen.
l
Documentation
– Whether or not documentation (e.g. a requirements
specification) exists and whether or not it is up to date will affect the choice of
testing techniques. The content and style of the documentation will also influence
the choice of techniques (for example, if decision tables or state graphs have been
used then the associated test techniques should be used).
l
Life cycle model
– A sequential life cycle model will lend itself to the use of more
formal techniques whereas an iterative life cycle model may be better suited to
using an exploratory testing approach.
The external factors that influence the decision about which technique to use are:
l
Risk
– The greater the risk (e.g. safety-critical systems), the greater the need
for more thorough and more formal testing. Commercial risk may be influenced
by quality issues (so more thorough testing would be appropriate) or by
time-to-market issues (so exploratory testing would be a more appropriate
choice).
l
Customer/contractual requirements
– Sometimes contracts specify particular
testing techniques to use (most commonly statement or branch coverage).
l
Type of system
– The type of system (e.g. embedded, graphical, financial, etc.)
will influence the choice of techniques. For example, a financial application
involving many calculations would benefit from boundary value analysis.
l
Regulatory requirements
– Some industries have regulatory standards or
guidelines that govern the testing techniques used. For example, the aircraft
industry requires the use of equivalence partitioning, boundary value analysis and
state transition testing for high integrity systems together with statement, decision
or modified condition decision coverage depending on the level of software
integrity required.
Section 6 Choosing Test Techniques 109

l
Time and budget
– Ultimately how much time there is available will always
affect the choice of testing techniques. When more time is available we can
afford to select more techniques and when time is severely limited we will be
limited to those that we know have a good chance of helping us find just the most
important defects.
It
’s important to remember that intelligent, experienced testers see test design
techniques
– and indeed test strategies, which we’ll discuss in Chapter 5 – as tools to
be employed wherever needed and useful. You should use whatever techniques and
strategies, in whatever combinations, make sense to ensure adequate coverage of the
system under test, and achievement of the objectives of testing. Feel free to combine
the test design techniques discussed in this chapter with whatever inspiration you
have, along with process, rule and data-driven techniques. Use your brain, and do
what makes sense.
110
Chapter 4 Test design techniques

C H A P T E R R E V I E W
Let
’s review what you have learned in this chapter.
From Section 4.1, you should now be able to differentiate between a test
condition, a test case and a test procedure, and know that they are documented in
a test design specification, a test case specification and a test procedure specification
respectively. You should be able to write test cases that include expected results and
that show clear traceability to the test basis (e.g. requirements). You should be able
to translate test cases into a test procedure specification at the appropriate level of
detail for testers and you should be able to write a test execution schedule for a
given set of test cases that takes into account priorities as well as technical and
logical dependencies. You should know the glossary terms horizontal traceability,
test case specification, test design specification, test design technique, test
execution schedule, test script, traceability and vertical traceability.
From Section 4.2 (categories of test design techniques), you should be able to
give reasons why both specification-based (black-box), structure-based (white-box),
and experience-based approaches are useful, and list the common techniques for
each of these approaches. You should be able to explain the characteristics and
differences between specification-based, structure-based and experience-based tech-
niques. You should know the glossary terms experience-based test design techni-
que, specification-based test design technique, structure-based and test design
technique.
From Section 4.3, you should be able to write test cases from given software
models using equivalence partitioning, boundary value analysis, decision tables and
state transition diagrams. You should understand the main purpose of each of these
four techniques, what level and type of testing could use each technique and how
coverage can be measured for each of them. You should also understand the concept
and benefits of use case testing. You should know the glossary terms boundary
value, boundary value analysis, decision table, decision table testing, equiva-
lence partition, equivalence partitioning, state diagram, state table, state transi-
tion testing, and use case testing.
From Section 4.4, you should be able to describe the concept and importance of
code coverage. You should be able to explain the concepts of statement and decision
coverage and understand that these concepts can also be used at test levels other than
component testing (such as business procedures at system test level). You should be
able to write test cases from given control flows using statement testing and decision
testing, and you should be able to assess statement and decision coverage for
completeness. You should know the glossary terms branch coverage, code cover-
age, coverage, decision coverage, statement coverage, and test coverage.
From Section 4.5, you should be able to remember the reasons for writing test
cases based on intuition, experience and knowledge about common defects and you
should be able to compare experience-based techniques with specification-based
techniques. You should know the glossary terms attack, exploratory testing and
fault attack.
From Section 4.6, you should be able to list the factors that influence the
selection of the appropriate test design technique for a particular type of problem,
such as the type of system, risk, customer requirements, models for use case
modelling, requirements models or testing knowledge. There are no glossary terms
for this section.
Chapter Review 111

S A M P L E E X A M Q U E S T I O N S
Question 1 In which document described in IEEE
829 would you find instructions for the steps to be
taken for a test including set-up, logging, environment
and measurement?
a. Test plan
b. Test design specification
c. Test case specification
d. Test procedure specification
Question 2 With a highly experienced tester with
a good business background, which approach to
defining test procedures would be effective and
most efficient for a project under severe time
pressure?
a. A high-level outline of the test conditions and
general steps to take.
b. Every step in the test spelled out in detail.
c. A high-level outline of the test conditions with the
steps to take discussed in detail with another
experienced tester.
d. Detailed documentation of all test cases and careful
records of each step taken in the testing.
Question 3 Put the test cases that implement the
following test conditions into the best order for the
test execution schedule, for a test that is checking
modifications of customers on a database.
1 Print modified customer record.
2 Change customer address: house number and street
name.
3 Capture and print the on-screen error message.
4 Change customer address: postal code.
5 Confirm existing customer is on the database by
opening that record.
6 Close the customer record and close the database.
7 Try to add a new customer with no details at all.
a. 5, 4, 2, 1, 3, 7, 6
b. 4, 2, 5, 1, 6, 7, 3
c. 5, 4, 2, 1, 7, 3, 6
d. 5, 1, 2, 3, 4, 7, 6
Question 4 Why are both specification-based and
structure-based testing techniques useful?
a. They find different types of defect.
b. Using more techniques is always better.
c. Both find the same types of defect.
d. Because specifications tend to be unstructured.
Question 5 What is a key characteristic of structure-
based testing techniques?
a. They are mainly used to assess the structure of
a specification.
b. They are used both to measure coverage and to
design tests to increase coverage.
c. They are based on the skills and experience of the
tester.
d. They use a formal or informal model of the
software or component.
Question 6 Which of the following would be an
example of decision-table testing for a financial
application applied at the system-test level?
a. A table containing rules for combinations of inputs
to two fields on a screen.
b. A table containing rules for interfaces between
components.
c. A table containing rules for mortgage applications.
d. A table containing rules for chess.
Question 7 Which of the following could be
a coverage measure for state transition testing?
V All states have been reached.
W The response time for each transaction is adequate.
X Every transition has been exercised.
Y All boundaries have been exercised.
Z Specific sequences of transitions have been
exercised.
a. X, Y and Z
b. V, X, Y and Z
c. W, X and Y
d. V, X and Z
112
Chapter 4 Test design techniques

Question 8 Postal rates for
‘light letters’ are 25p up
to 10g, 35p up to 50g plus an extra 10p for each
additional 25g up to 100g.
Which test inputs (in grams) would be selected
using equivalence partitioning?
a. 8, 42, 82, 102
b. 4, 15, 65, 92, 159
c. 10, 50, 75, 100
d. 5, 20, 40, 60, 80
Question 9 Which of the following could be used to
assess the coverage achieved for specification-based
(black-box) test techniques?
V Decision outcomes exercised
W Partitions exercised
X Boundaries exercised
Y State transitions exercised
Z Statements exercised
a. V, W, Y or Z
b. W, X or Y
c. V, X or Z
d. W, X, Y or Z
Question 10 Which of the following would
structure-based test design techniques be most likely
to be applied to?
1 Boundaries between mortgage interest rate bands.
2 An invalid transition between two different arrears
statuses.
3 The business process flow for mortgage approval.
4 Control flow of the program to calculate
repayments.
a. 2, 3 and 4
b. 2 and 4
c. 3 and 4
d. 1, 2 and 3
Question 11 Use case testing is useful for which of
the following?
P Designing acceptance tests with users or
customers.
Q Making sure that the mainstream business
processes are tested.
R Finding defects in the interaction between
components.
S Identifying the maximum and minimum values for
every input field.
T Identifying the percentage of statements exercised
by a sets of tests.
a. P, Q and R
b. Q, S and T
c. P, Q and S
d. R, S and T
Question 12 Which of the following statements
about the relationship between statement coverage
and decision coverage is correct?
a. 100% decision coverage is achieved if statement
coverage is greater than 90%.
b. 100% statement coverage is achieved if decision
coverage is greater than 90%.
c. 100% decision coverage always means 100%
statement coverage.
d. 100% statement coverage always means 100%
decision coverage.
Question 13 If you are flying with an economy
ticket, there is a possibility that you may get
upgraded to business class, especially if you hold
a gold card in the airline
’s frequent flier program.
If you don
’t hold a gold card, there is a possibility
that you will get
‘bumped’ off the flight if it is
full and you check in late. This is shown in
Figure 4.5. Note that each box (i.e. statement)
has been numbered.
Three tests have been run:
Test 1: Gold card holder who gets upgraded to
business class.
Test 2: Non-gold card holder who stays in
economy.
Test 3: A person who is bumped from the flight.
What is the statement coverage of these
three tests?
a. 60%
b. 70%
c. 80%
d. 90%
Sample Exam Questions 113

Question 14 Why are error guessing and
exploratory testing good to do?
a. They can find defects missed by specification-
based and structure-based techniques.
b. They don
’t require any training to be as effective
as formal techniques.
c. They can be used most effectively when there are
good specifications.
d. They will ensure that all of the code or system is
tested.
Question 15 How do experience-based techniques
differ from specification-based techniques?
a. They depend on the tester
’s understanding of the
way the system is structured rather than on a
documented record of what the system should do.
b. They depend on having older testers rather than
younger testers.
c. They depend on a documented record of what the
system should do rather than on an individual
’s
personal view.
d. They depend on an individual
’s personal view
rather than on a documented record of what the
system should do.
Question 16 When choosing which technique to use
in a given situation, which factors should be taken
into account?
U Previous experience of types of defects found in
this or similar systems.
V The existing knowledge of the testers.
W Regulatory standards that apply.
X The type of test execution tool that will be used.
Y The documentation available.
Z Previous experience in the development language.
a. V, W, Y and Z
b. U, V, W and Y
c. U, X and Y
d. V, W and Y
Question 17 Given the state diagram in Figure 4.6,
which test case is the minimum series of valid
transitions to cover every state?
a. SS
– S1 – S2 – S4 – S1 – S3 – ES
b. SS
– S1 – S2 – S3 – S4 – ES
c. SS
– S1 – S2 – S4 – S1 – S3 – S4 – S1 – S3 – ES
d. SS
– S1 – S4 – S2 – S1 – S3 – ES
gold
card?
1
business
class full?
2
economy
6
business
class full?
8
7
upgrade
9
economy
3
upgrade
4
boarding
card
5
bump off
flight
10
N
N
N
Y
Y
Y
Y
N
economy
full?
F I G U R E 4 . 5
Control flow diagram for flight check-in
SS 
S1 
S4 
S2 
S3 
ES
F I G U R E 4 . 6
State diagram for PIN entry
114
Chapter 4 Test design techniques

E X E R C I S E S : T E S T D E S I G N T E C H N I Q U E S
Exercises based on the techniques covered in this chapter are given in this section. Worked solutions are given in
the next section.
Equivalence Partitioning/Boundary Value Analysis exercise
Scenario: If you take the train before 9:30 am or in the afternoon after 4:00 pm until 7:30 pm (‘the rush hour’),
you must pay full fare. A saver ticket is available for trains between 9:30 am and 4:00 pm, and after 7:30 pm.
What are the partitions and boundary values to test the train times for ticket types? Which are valid partitions
and which are invalid partitions? What are the boundary values? (A table may be helpful to organize your

tải về 6.34 Mb.

Chia sẻ với bạn bè của bạn: