particular decision outcome (e.g. a False exit from an IF statement) that no test

particular decision outcome (e.g. a False exit from an IF statement) that no test
has taken so far, and may then also be able to calculate the test input required to
force execution to take that decision outcome.
Features or characteristics of coverage measurement tools include support for:
l
identifying coverage items (instrumenting the code);
l
calculating the percentage of coverage items that were exercised by a suite of
tests;
l
reporting coverage items that have not been exercised as yet;
l
identifying test inputs to exercise as yet uncovered items (test design tool
functionality);
l
generating stubs and drivers (if part of a unit test framework).
Note that the coverage tools only measure the coverage of the items that they can
identify. Just because your tests have achieved 100% statement coverage, this does
not mean that your software is 100% tested!
Coverage tool A tool
that provides objective
measures of what
structural elements, e.g.
statements, branches
have been exercised by a
test suite.
172
Chapter 6 Tool support for testing

Security testing tools
There are a number of tools that protect systems from external attack, for example
firewalls, which are important for any system.
Security testing tools can be used to test security by trying to break into a
system, whether or not it is protected by a security tool. The attacks may focus on
the network, the support software, the application code or the underlying database.
Features or characteristics of security testing tools include support for:
l
identifying viruses;
l
detecting intrusions such as denial of service attacks;
l
simulating various types of external attacks;
l
probing for open ports or other externally visible points of attack;
l
identifying weaknesses in password files and passwords;
l
security checks during operation, e.g. for checking integrity of files, and
intrusion detection, e.g. checking results of test attacks.
6.1.7 Tool support for performance and monitoring
The tools described in this section support testing that can be carried out on a system
when it is operational, i.e. while it is running. This can be during testing or could be
after a system is released into live operation.
Dynamic analysis tools (D)
Dynamic analysis tools are ‘dynamic’ because they require the code to be running.
They are
‘analysis’ rather than ‘testing’ tools because they analyze what is happen-
ing
‘behind the scenes’ while the software is running (whether being executed with
test cases or being used in operation).
An analogy with a car may be useful here. If you go to look at a car to buy, you
might sit in it to see if is comfortable and see what sound the doors make
– this would
be static analysis because the car is not being driven. If you take a test drive, then you
would check that the car performs as you expect (e.g. turns right when you turn the
steering wheel clockwise)
– this would be a test. While the car is running, if you were
to check the oil pressure or the brake fluid, this would be dynamic analysis
– it can
only be done while the engine is running, but it isn
’t a test case.
When your PC
’s response time gets slower and slower over time, but is much
improved after you re-boot it, this may well be due to a
‘memory leak’, where the
programs do not correctly release blocks of memory back to the operating system.
Eventually the system will run out of memory completely and stop. Rebooting
restores all of the memory that was lost, so the performance of the system is now
restored to its normal state.
Features or characteristics of dynamic analysis tools include support for:
l
detecting memory leaks;
l
identifying pointer arithmetic errors such as null pointers;
l
identifying time dependencies.
These tools would typically be used by developers in component testing and
component integration testing, e.g. when testing middleware, when testing security
or when looking for robustness defects.
Security testing tool
A tool that provides
support for testing
security characteristics
and vulnerabilities.
Security Attributes of
software products that
bear on its ability to
prevent unauthorized
access, whether
accidental or deliberate,
to programs and data.
security tool A tool that
supports operational
security.
Dynamic analysis
tool A tool that provides
run-time information on
the state of the software
code. These tools are
most commonly used to
identify unassigned
pointers, check pointer
arithmetic and to monitor
the allocation, use and
de-allocation of memory
and to flag memory
leaks.
Section 1 Types of Test Tool 173

Another form of dynamic analysis for websites is to check whether each link
does actually link to something else (this type of tool may be called a
‘web spider’).
The tool doesn
’t know if you have linked to the correct page, but at least it can find
dead links, which may be helpful.
Performance-testing, load-testing and stress-testing tools
Performance-testing tools are concerned with testing at system level to see whether
or not the system will stand up to a high volume of usage. A
‘load’ test checks that
the system can cope with its expected number of transactions. A ‘volume’ test
checks that the system can cope with a large amount of data, e.g. many fields in a
record, many records in a file, etc. A ‘stress’ test is one that goes beyond the normal
expected usage of the system (to see what would happen outside its design expecta-
tions), with respect to load or volume.
In performance testing, many test inputs may be sent to the software or system
where the individual results may not be checked in detail. The purpose of the test is
to measure characteristics, such as response times, throughput or the mean time
between failures (for reliability testing).
In order to assess performance, the tool needs to generate some kind of activity on
the system, and this can be done in different ways. At a very simple level the same
transaction could be repeated many times, but this is not realistic. There are many levels
of realism that could be set, depending on the tool, such as different user profiles,
different types of activity, timing delays and other parameters. Adequately replicating
the end-user environments or user profiles is usually key to realistic results.
Analyzing the output of a performance-testing tool is not always straightforward
and it requires time and expertise. If the performance is not up to the standard
expected, then some analysis needs to be performed to see where the problem is and
to know what can be done to improve the performance.
Features or characteristics of performance-testing tools include support for:
l
generating a load on the system to be tested;
l
measuring the timing of specific transactions as the load on the system varies;
l
measuring average response times;
l
producing graphs or charts of responses over time.
Monitoring tools
Monitoring tools are used to continuously keep track of the status of the system in
use, in order to have the earliest warning of problems and to improve service. There
are monitoring tools for servers, networks, databases, security, performance, website
and internet usage, and applications.
Features or characteristics of monitoring tools include support for:
l
identifying problems and sending an alert message to the administrator
(e.g. network administrator);
l
logging real-time and historical information;
l
finding optimal settings;
l
monitoring the number of users on a network;
l
monitoring network traffic (either in real time or covering a given length of
time of operation with the analysis performed afterwards).
Performance-testing
tool (load-testing
tool) A tool to support
performance testing that
usually has two main
facilities: load generation
and test transaction
measurement. Load
generation can simulate
either multiple users or
high volumes of input
data. During execution,
response time
measurements are taken
from selected
transactions and these
are logged. Performance
testing tools normally
provide reports based on
test logs and graphs of
load against response
times.
Volume testing Testing
where the system is
subjected to large
volumes of data.
Stress testing tool A
tool that supports stress
testing.
Monitor (monitoring
tool) A software tool or
hardware device that
runs concurrently with
the component or system
under test and
supervises, records and/or
analyzes the behaviour of
the component or
system.
174
Chapter 6 Tool support for testing

6.1.8 Tool support for specific application areas (K1)
In this chapter, we have described tools according to their general functional classifica-
tions. There are also further specializations of tools within these classifications. For
example there are web-based performance-testing tools as well as performance-testing
tools for back-office systems. There are static analysis tools for specific development
platforms and programming languages, since each programming language and every
platform has distinct characteristics. There are dynamic analysis tools that focus on
security issues, as well as dynamic analysis tools for embedded systems.
Commercial tool sets may be bundled for specific application areas such as web-
based or embedded systems.
6.1.9 Tool support using other tools
The tools described in this chapter are not the only tools that a tester can make use of.
You may not normally think of a word processor or a spreadsheet as a testing tool, but
they are often used to store test designs, test scripts or test data. Testers may also use
SQL to set up and query databases containing test data. Tools used by developers
when debugging, to help localize defects and check their fixes, are also testing tools.
Developers use debugging tools when identifying and fixing defects. The debug-
ging tools enable them to run individual and localized tests to ensure that they have
correctly identified the cause of a defect and to confirm that their change to the code
will indeed fix the defect.
6.1.10 Tool support for specific testing needs
We can also use tools for data quality assessment. In many IT-centric organizations,
systems and systems of systems manage tremendous volumes of complex, inter-related
data. This puts data at the centre of many projects in these organizations, including data
conversion and migration projects and data warehouse projects. The data involved can
vary in terms of criticality and volume. You can
– and often should – use tools as part of the
data quality assessment, including reviewing and verifying data conversion and migration
rules. Tools can help ensure that the processed data is correct, and complete, and that it
complies to pre-defined, context-specific standards, even when the volume of data is large.
You can also use tools for usability testing. These can include general-purpose
tools such as video recorders and screen-capture utilities.
6 . 2
E F F E C T I V E U S E O F T O O L S : P O T E N T I A L
B E N E F I T S A N D R I S K S
SYLLABUS LEARNING OBJECTIVES FOR 6.2 EFF ECTIVE USE
OF TOOLS: POTENTIAL BENEFITS AND RISKS(K2)
LO-6.2.1 Summarize the potential benefits and risks of test automation
and tool support for testing. (K2)
LO-6.2.2 Remember special considerations for test execution tools,
static analysis, and test management tools. (K1)
Debugging tool A tool
used by programmers to
reproduce failures,
investigate the state of
programs and find the
corresponding defect.
Debuggers enable
programmers to execute
programs step by step, to
halt a program at any
program statement and
to set and examine
program variables.
Section 2 Effective use of Tools: Potential Benefits and Risks 175

The reason for acquiring tools to support testing is to gain benefits, by using a software
program to do certain tasks that are better done by a computer than by a person.
Advice on introducing tools into an organization can be found in web articles,
magazines and books such as [Siteur 2005] and [Fewster and Graham 1999].
As we go through this section, watch for the Syllabus term scripting language.
You
’ll find these terms defined in the glossary.
6.2.1 Potential benefits of using tools
There are many benefits that can be gained by using tools to support testing, whatever
the specific type of tool. Benefits include:
l
reduction of repetitive work;
l
greater consistency and repeatability;
l
objective assessment;
l
ease of access to information about tests or testing.
Repetitive work is tedious to do manually. People become bored and make
mistakes when doing the same task over and over. Examples of this type of
repetitive work include running regression tests, entering the same test data over
and over again (both of which can be done by a test execution tool), checking
against coding standards (which can be done by a static analysis tool) or creating a
specific test database (which can be done by a test data preparation tool).
People tend to do the same task in a slightly different way even when they think they
are repeating something exactly. A tool will exactly reproduce what it did before, so each
time it is run the result is consistent. Examples of where this aspect is beneficial include
checking to confirm the correctness of a fix to a defect (which can be done by a debugging
tool or test execution tool), entering test inputs (which can be done by a test execution
tool) and generating tests from requirements (which can be done by a test design tool or
possibly a requirements management tool).
If a person calculates a value from the software or incident reports, they may
inadvertently omit something, or their own subjective prejudices may lead them to
interpret that data incorrectly. Using a tool means that subjective bias is removed
and the assessment is more repeatable and consistently calculated. Examples include
assessing the cyclomatic complexity or nesting levels of a component (which can be
done by a static analysis tool), coverage (coverage measurement tool), system
behaviour (monitoring tools) and incident statistics (test management tool or inci-
dent management tool).
Having lots of data doesn
’t mean that information is communicated. Information
presented visually is much easier for the human mind to take in and interpret. For
example, a chart or graph is a better way to show information than a long list of
numbers
– this is why charts and graphs in spreadsheets are so useful. Special
purpose tools give these features directly for the information they process. Examples
include statistics and graphs about test progress (test execution or test management
tool), incident rates (incident management or test management tool) and performance
(performance testing tool).
In addition to these general benefits, each type of tool has specific benefits relating
to the aspect of testing that the particular tool supports. These benefits are normally
prominently featured in the information available for the type of tool. It is worth
investigating a number of different tools to get a general view of the benefits.
176
Chapter 6 Tool support for testing

6.2.2 Risks of using tools
Although there are significant benefits that can be achieved using tools to support testing
activities, there are many organizations that have not achieved the benefits they expected.
Simply purchasing a tool is no guarantee of achieving benefits, just as buying
membership in a gym does not guarantee that you will be fitter. Each type of tool
requires investment of effort and time in order to achieve the potential benefits.
There are many risks that are present when tool support for testing is introduced
and used, whatever the specific type of tool. Risks include:
l
unrealistic expectations for the tool;
l
underestimating the time, cost and effort for the initial introduction of a tool;
l
underestimating the time and effort needed to achieve significant and
continuing benefits from the tool;
l
underestimating the effort required to maintain the test assets generated by
the tool;
l
over-reliance on the tool, including relying on tools for test design or test
execution where manual testing would work better;
l
failing to use proper configuration management and version control facilities
for the test assets created for and by the tool;
l
failing to consider and manage issues related to relationships and interoperability
between critical tools, such as requirements management tools, version control
tools, incident management tools, defect tracking tools and tools from multiple
vendors;
l
possibility of the tool vendor going out of business, retiring the tool, or selling
the tool to a different vendor, or in the open-source world, the possibility of
orphanage of the tool or suspension of the project by the open-source
community;
l
poor or completely non-existent vendor response, whether for support,
upgrades, or defect fixes;
l
various uncertainties and unforeseen problems, such as the inability to support
a new platform.
Unrealistic expectations may be one of the greatest risks to success with tools.
The tools are only software and we all know that there are many problems with any
kind of software! It is important to have clear objectives for what the tool can do and
that those objectives are realistic.
Introducing something new into an organization is seldom straightforward. Hav-
ing purchased a tool, you will want to move from opening the box to having a
number of people being able to use the tool in a way that will bring benefits. There
will be technical problems to overcome, but there will also be resistance from other
people
– both need to be addressed in order to succeed in introducing a tool.
Think back to the last time you did something new for the very first time (learning to
drive, riding a bike, skiing). Your first attempts were unlikely to be very good but with
more experience you became much better. Using a testing tool for the first time will not
be your best use of the tool either. It takes time to develop ways of using the tool in
order to achieve what is possible. Fortunately there are some short-cuts (e.g. reading
books and articles about other people
’s experiences and learning from them). See also
Section 6.3 for more detail on introducing a tool into an organization.
Section 2 Effective use of Tools: Potential Benefits and Risks 177

Insufficient planning for maintenance of the assets that the tool produces is a
strong contributor to tools that end up as
‘shelf-ware’, along with the previously
listed risks. Although particularly relevant for test execution tools, planning for
maintenance is also a factor with other types of tool.
Tools are definitely not magic! They can do very well what they have been
designed to do (at least a good quality tool can), but they cannot do everything. A
tool can certainly help, but it does not replace the intelligence needed to know how
best to use it, and how to evaluate current and future uses of the tool. For example, a
test execution tool does not replace the need for good test design and should not be
used for every test
– some tests are still better executed manually. A test that takes a
very long time to automate and will not be run very often is better done manually.
This list of risks is not exhaustive. Two other important factors are:
l
the skill needed to create good tests;
l
the skill needed to use the tools well, depending on the type of tool.
The skills of a tester are not the same as the skills of the tool user. The tester
concentrates on what should be tested, what the test cases should be and how to
prioritize the testing. The tool user concentrates on how best to get the tool to do its
job effectively and how to give increasing benefit from tool use.
6.2.3 Special considerations for some types of tools
Test execution tools
In order to know what tests to execute and how to run them, the test execution tool
must have some way of knowing what to do
– this is the script for the tool. But
since the tool is only software, the script must be completely exact and unambig-
uous to the computer (which has no common sense). This means that the script
becomes a program, written in a programming language. The scripting language
may be specific to a particular tool, or it may be a more general language.
Scripting languages are not used just by test execution tools, but the scripts used
by the tool are stored electronically to be run when the tests are executed under the
tool
’s control.
There are tools that can generate scripts by identifying what is on the screen
rather than by capturing a manual test, but they still generate scripts to be used in
execution; they are not script-free.
There are different levels of scripting. Five are described in [Fewster and Graham
1999]:
l
linear scripts (which could be created manually or captured by recording a
manual test);
l
structured scripts (using selection and iteration programming structures);
l
shared scripts (where a script can be called by other scripts so can be
re-used
– shared scripts also require a formal script library under configuration
management);
l
data-driven scripts (where test data is in a file or spreadsheet to be read by a
control script);
l
keyword-driven scripts (where all of the information about the test is stored in
a file or spreadsheet, with a single control scripts that implements the tests
described in the file using shared and keyword scripts.
scripting language
A programming
language in which
executable test scripts are
written, used by a test
execution tool (e.g. a
capture/playback tool).
178
Chapter 6 Tool support for testing

Capturing a manual test seems like a good idea to start with, particularly if you
are currently running tests manually anyway. But a captured test (a linear script) is
not a good solution, for a number of reasons, including:
l
The script doesn
’t know what the expected result is until you program it
in
– it only stores inputs that have been recorded, not test cases.
l
A small change to the software may invalidate dozens or hundreds of scripts.
l
The recorded script can only cope with exactly the same conditions as when it
was recorded. Unexpected events (e.g. a file that already exists) will not be
interpreted correctly by the tool.
However, there are some times when capturing test inputs (i.e. recording a manual
test) is useful. For example, if you are doing exploratory testing or if you are running
unscripted tests with experienced business users, it can be very helpful simply to log
everything that is done, as an audit trail. This serves as a form of documentation of
what was tested (although analyzing it may not be easy). This audit trail can also be
very useful if a failure occurs which cannot be easily reproduced
– the recording of the
specific failure can be played to the developer to see exactly what sequence caused the
problem.
Captured test inputs can be useful in the short term, where the context remains
valid. Just don
’t expect to replay them as regression tests (when the context of the
test may be different). Captured tests may be acceptable for a few dozen tests, where
the effort to update them when the software changes is not very large. Don
’t expect
a linear-scripting approach to scale to hundreds or thousands of tests.
So capturing tests does have a place, but it is not a large place in terms of
automating test execution.
Data driven scripts allow the data, i.e. the test inputs and expected outcomes, to
be stored separately from the script. This can include situations where, instead of the
testing putting hard-coded data combinations in a spreadsheet, a tool generates and
supplies data in real time, based on configurable parameters. For example, a tool
may generate a random user ID for accounts, and can take advantage of random-
number seeding to ensuring repeatability in the pattern of user IDs. Whichever way
data-driven scripts are implemented, they have the advantage that a tester who
doesn
’t know how to use a scripting language can populate a file or spreadsheet
with the data for a specific test. This is particularly useful when there are a large
number of data values that need to be tested using the same control script.
Keyword-driven scripts include not just data but also keywords in the data file or
spreadsheet. In other words, the spreadsheet or data file contains keywords that
describe the actions to be taken and the test data. (
‘Action words’ is another term
used for keywords.) Keyword-driven (or action-word) automation enables a tester
(who is not a script programmer) to devise a great variety of tests (not just the test
input data for essentially the same test, as in data-driven scripts). The tester needs to
know what keywords are currently available to use (by someone having written a
script for it) and what data the keyword is expecting, but the tester can then write
tests, not just test data. The tester can also request additional keywords to be added
to the available programmed set of scripts as needed. Keywords can deal with both
test inputs and expected outcomes.
Of course, someone still needs to be able to use the tool directly and be able to
program in the tool
’s scripting language in order to write and debug the scripts that
will use the data tables or keyword tables. A small number of automation specialists
data-driven A scripting
technique that stores test
input and expected
results in a table or
spreadsheet, so that a
single control script can
execute all of the tests in
the table. Data driven
testing is often used to
support the application
of test execution tools
such as capture/playback
tools.
Section 2 Effective use of Tools: Potential Benefits and Risks 179

can support a larger number of testers, who then don
’t need to learn to be script
programmers (unless they want to).
The data files (data-driven or keyword-driven) include the expected results for
the tests. The actual results from each test run also need to be stored, at least until
they are compared to the expected results and any differences are logged.
More information on data-driven and keyword-driven scripting can be found in
[Fewster and Graham 1999].
Performance testing tools
Performance testing is developing into a specialized discipline of its own. With
functional testing, the types of defect that we are looking for are functionality
– does
the system or component produce the correct result for given inputs? In perfor-
mance testing, we are not normally concerned so much with functional correctness,
but with non-functional quality characteristics. When using a performance testing
tool we are looking at the transaction throughput, the degree of accuracy of a given
computation, the computer resources being used for a given level of transactions,
the time taken for certain transactions or the number of users that can use the system
at once.
In order to get the best from a performance-testing tool, it is important to under-
stand what the tool can and cannot do for you. Although this is true for other types of
tool as well, there are particular issues with performance-testing tools, including:
l
the design of the load to be generated by the tool (e.g. random input or
according to user profiles);
l
timing aspects (e.g. inserting delays to make simulated user input more realistic);
l
the length of the test and what to do if a test stops prematurely;
l
narrowing down the location of a bottleneck;
l
exactly what aspects to measure (e.g. user interaction level or server level);
l
how to present the information gathered.
Static analysis tools
Static analysis tools are very useful to developers, as they can identify potential
problems in code before the code is executed and they can also help to check that
the code is written to coding standards.
When a static analysis tool is first introduced, there can be some problems. For
example, if the tool checks the current coding standard against code written several
years ago, there may be a number of things found in the old code that fail to meet
the new coding standard now in place. If the old code has been working well for
years, it is probably not a good idea to change it just to satisfy the new coding
standard (unless changes are necessary for some other reason). There is a risk that
the changes to meet the new standard may have inadvertent side-effects which may
not be picked up by regression testing.
Static analysis tools can generate a large number of messages, for example by
finding the same thing every few lines. This can be rather annoying, especially if the
things found are not considered important now, for example warnings rather than
potential defects.
The aim of the static analysis tool is to produce code that will be easier to
maintain in the future, so it would be a good idea to implement higher standards on
new code that is still being tested, before it is released into use, but to allow older
180
Chapter 6 Tool support for testing

code to be less stringently checked. There is still a risk that the changes to conform
to the new standard will introduce an unexpected side-effect, but there is a much
greater likelihood that it will be found in testing and there is time to fix it before the
system is released.
A filter on the output of the static analysis tool could eliminate some of the less
important messages and make the more important messages more likely to be
noticed and fixed.
Test management tools
Test management tools can provide a lot of useful information, but the information
as produced by the tool may not be in the form that will be most effective within
your own context. Some additional work may be needed to produce interfaces to
other tools or a spreadsheet in order to ensure that the information is communicated
in the most effective way.
A report produced by a test management tool (either directly or indirectly through
another tool or spreadsheet) may be a very useful report at the moment, but may not
be useful in three or six months. It is important to monitor the information produced
to ensure it is the most relevant now.
It is important to have a defined test process before test management tools are
introduced. If the testing process is working well manually, then a test manage-
ment tool can help to support the process and make it more efficient. If you adopt a
test management tool when your own testing processes are immature, one option is
to follow the standards and processes that are assumed by the way the tool works.
This can be helpful; but it is not necessary to follow the vendor-specific processes.
The best approach is to define your own processes, taking into account the tool
you will be using, and then adapt the tool to provide the greatest benefit to your
organization.
6 . 3
I N T R O D U C I N G A T O O L I N T O A N
O R G A N I Z A T I O N
SYLLABUS LEARNING OBJECTIVES FOR 6 .3 INTRODUCING
A TOOL INTO AN ORGANIZATION (K1)
LO-6.3.1 State the main principles of introducing a tool into an
organization. (K1)
LO-6.3.2 State the goals of a proof-of-concept for tool evaluation and a
piloting phase for tool implementation. (K1)
LO-6.3.3 Recognize that factors other than simply acquiring a tool are
required for good tool support. (K1)
In this section, we discuss the principles and process of introducing automated
testing tools into your organization. We look at the process of tool selection. We
’ll
talk about how to carry out tool pilot programs. We
’ll conclude with thoughts on
what makes tool introduction successful.
There are no Syllabus terms for this section.
Section 3 Introducing a Tool into an Organization 181

6.3.1 Main principles
The place to start when introducing a tool into an organization is not with the tool
–
it is with the organization. In order for a tool to provide benefit, it must match a need
within the organization, and solve that need in a way that is both effective and
efficient. The tool should help to build on the strengths of the organization and
address its weaknesses. The organization needs to be ready for the changes that will
come with the new tool. If the current testing practices are not good and the
organization is not mature, then it is generally more cost-effective to improve testing
practices rather than to try to find tools to support poor practices. Automating chaos
just gives faster chaos!
Of course, we can sometimes improve our own processes in parallel with introducing
a tool to support those practices and we can pick up some good ideas for improvement
from the ways that the tools work. However, be aware that the tool should not take the
lead, but should provide support to what your organization defines.
The following factors are important in selecting a tool:
l
assessment of the organization
’s maturity (e.g. readiness for change);
l
identification of the areas within the organization where tool support will help
to improve testing processes;
l
evaluation of tools against clear requirements and objective criteria;
l
proof-of-concept to see whether the product works as desired and meets the
requirements and objectives defined for it;
l
evaluation of the vendor (training, support and other commercial aspects) or
open-source network of support;
l
identifying and planning internal implementation (including training, coaching
and mentoring for those new to the use of the tool);
l
estimation of the return on investment (cost-benefit ratio) based on a concrete
and realistic business case.
6.3.2 Pilot project
One of the ways to do a proof-of-concept is to have a pilot project as the first thing
done with a new tool. This will use the tool in earnest but on a small scale, with
sufficient time to explore different ways of using the tool. Objectives should be set
for the pilot in order to assess whether or not the concept is proven, i.e. that the tool
can accomplish what is needed within the current organizational context.
A pilot tool project should expect to encounter problems
– they should be solved
in ways that can be used by everyone later on. The pilot project should experiment
with different ways of using the tool. For example, different settings for a static
analysis tool, different reports from a test management tool, different scripting and
comparison techniques for a test execution tool or different load profiles for a
performance-testing tool.
The objectives for a pilot project for a new tool are:
l
to learn more about the tool (more detail, more depth);
l
to see how the tool would fit with existing processes or documentation, how
those would need to change to work well with the tool and how to use the tool
to streamline existing processes;
182
Chapter 6 Tool support for testing

l
to decide on standard ways of using the tool that will work for all potential
users (e.g. naming conventions, creation of libraries, defining modularity,
where different elements will be stored, how they and the tool itself will be
maintained);
l
to evaluate the pilot project against its objectives (have the benefits been
achieved at reasonable cost?).
6.3.3 Success factors
Success is not guaranteed or automatic when implementing a testing tool, but many
organizations have succeeded. Here are some of the factors that have contributed to
success:
l
incremental roll-out (after the pilot) to the rest of the organization;
l
adapting and improving processes, testware and tool artefacts to get the best
fit and balance between them and the use of the tool;
l
providing adequate support, training, coaching and mentoring of new users;
l
defining and communicating guidelines for the use of the tool, based on what
was learned in the pilot;
l
implementing a continuous improvement mechanism as tool use spreads
through more of the organization;
l
monitoring the use of the tool and the benefits achieved and adapting the use of
the tool to take account of what is learned;
l
provide continuing support for anyone using test tools, such as the test team;
for example, technical expertise is needed to help non-programmer testers who
use keyword-driven test automation;
l
continuous improvement of tool use should be based on information gathered
from all teams who are using test tools.
More information and advice about selecting and implementing tools can be
found in [Fewster and Graham 1999].
Section 3 Introducing a Tool into an Organization 183

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 6.1, you should now be able to classify different types of test tools
according to the test process activities that they support. You should also recognize
the tools that may help developers in their testing (shown by
‘(D)’ below). In
addition to the list below, you should recognize that there are tools that support
specific application areas and that general-purpose tools can also be used to support
testing. The tools you should now recognize are:
Tools that support the management of testing and tests:
– test management tool;
– requirements management tool;
– incident management tool;
– configuration management tool.
Tools that support static testing:
– review tool;
– static analysis tool (D);
– modelling tool (D).
Tools that support test specification:
– test design tool;
– test data preparation tool.
Tools that support test execution and logging:
– test execution tool;
– test harness and unit test framework tool (D);
– test comparator;
– coverage measurement tool (D);
– security tool.
Tools that support performance and monitoring:
– dynamic analysis tool;
– performance-testing, load-testing and stress-testing tool;
– monitoring tool.
In addition to the tools already listed, you should know the glossary terms capture/
playback tool, configuration management tool, coverage tool, debugging tool,
dynamic analysis tool, incident management tool, load testing tool, modelling tool,
monitoring tool, performance testing tool, probe effect, requirements management
tool, review tool, security testing tool, security tool, static analysis tool, static code
analysis, static code analyzer, stress testing tool, test comparator, test comparison,
test data preparation tool, test design tool, test framework, test execution tool, test
management tool, unit test framework tool and volume testing.
From Section 6.2, you should be able to summarize the potential benefits and
potential risks of tool support for testing in general. You should recognize that some
184
Chapter 6 Tool support for testing

tools have special considerations, including test execution tools, performance-testing
tools, static analysis tools and test management tools. You should know the glossary
term scripting language and recognize these as associated with test execution tools.
From Section 6.3, you should be able to state the main principles of introducing a
tool into an organization (e.g. assessing organizational maturity, clear requirements
and objective criteria, proof-of-concept, vendor evaluation, coaching and mentor-
ing). You should be able to state the goals of a proof-of-concept or piloting phase
for tool evaluation (e.g. learn about the tool, assess fit with current practices, decide
on standards, assess benefits). You should recognize that simply acquiring a tool is
not the only factor in achieving good tool support; there are many other factors that
are important for success (e.g. incremental roll-out, adapting processes, training and
coaching, defining usage guidelines, learning lessons and monitoring benefits).
There are no specific definitions for this section.
Chapter Review 185

S A M P L E E X A M Q U E S T I O N S
Question 1 Which tools help to support static
testing?
a. Static analysis tools, and test execution tools.
b. Review tools, static analysis tools, and coverage
measurement tools.
c. Dynamic analysis tools, and modelling tools.
d. Review tools, static analysis tools, and modelling
tools.
Question 2 Which test activities are supported
by test harness or unit test framework tools?
a. Test management and control.
b. Test specification and design.
c. Test execution and logging.
d. Performance and monitoring.
Question 3 What are the potential benefits from
using tools in general to support testing?
a. Greater quality of code, reduction in the number of
testers needed, better objectives for testing.
b. Greater repeatability of tests, reduction in
repetitive work, objective assessment.
c. Greater responsiveness of users, reduction of tests
run, objectives not necessary.
d. Greater quality of code, reduction in paperwork,
fewer objections to the tests.
Question 4 What is a potential risk in using tools
to support testing?
a. Unrealistic expectations, expecting the tool to do
too much.
b. Insufficient reliance on the tool, i.e. still doing
manual testing when a test execution tool has been
purchased.
c. The tool may find defects that aren
’t there.
d. The tool will repeat exactly the same thing it did
the previous time.
Question 5 Which of the following are advanced
scripting techniques for test execution tools?
a. Data-driven and keyword-driven.
b. Data-driven and capture-driven.
c. Capture-driven and keyhole-driven.
d. Playback-driven and keyword-driven.
Question 6 Which of the following would NOT
be done as part of selecting a tool for an organization?
a. Assess organizational maturity, strengths, and
weaknesses.
b. Roll out the tool to as many users as possible
within the organization.
c. Evaluate the tool features against clear
requirements and objective criteria.
d. Identify internal requirements for coaching and
mentoring in the use of the tool.
Question 7 Which of the following is a goal for a
proof-of-concept or pilot phase for tool evaluation?
a. Decide which tool to acquire.
b. Decide on the main objectives and requirements
for this type of tool.
c. Evaluate the tool vendor including training,
support, and commercial aspects.
d. Decide on standard ways of using, managing,
storing, and maintaining the tool and the test
assets.
186
Chapter 6 Tool support for testing

CHAPTER SEVEN
ISTQB Foundation Exam
W
e wrote (and re-wrote and re-wrote) this book specifically to cover the
International Software Testing Qualification Board (ISTQB) Foundation Syllabus
2011. As such, mastery of the previous six chapters should ensure that you master the
exam, too. Here are some thoughts on how to make sure you show how much you know
when taking the exam.
7 . 1
P R E P A R I N G F O R T H E E X A M
7.1.1 Studying for the exam
Whether you have taken a preparatory course along with reading this book or
just read the book, we have some study tips for certification candidates who
intend to take an exam under one of the ISTQB-recognized National Boards or
Exam Boards.
Of course, you should carefully study the Syllabus. If you encounter any state-
ments or concepts you do not completely understand, refer back to this book and to
any course materials used, to prepare for the exam. Exam questions often turn on
precise understanding of a concept.
While you should study the whole Syllabus, scrutinize the learning objectives in
the Syllabus one by one. Ask yourself if you have achieved that learning objective
to the given level of knowledge. If not, go back and review the appropriate material
in the section corresponding to that learning objective.
Going beyond the Syllabus, notice that a number of international standards are
referred to in the Syllabus. You should obtain copies of those standards and read
them. Some exam questions will be about the standards and glossary terms, and
often even experienced testers are unfamiliar with them.
We recommend that you try all of the sample exam questions in this book. If you
have understood the material in a chapter, you should have no trouble with the
questions. Make sure you understand why the right answer is the right answer and
why the wrong answers are wrong. If you cannot answer a question and don
’t
understand why, review that section.
We also recommend that you try all of the exercises in the book. If you can
answer them correctly, you probably understand the concepts. If you have not done
the exercises, you may well fail the exam.
Finally, be sure to take the mock exam we have provided at the end of this
chapter. If you have understood the material in the book, you should have no trouble
with most, if not all, of the questions on the mock exam. Make sure you carefully
review the book sections corresponding to any questions that you do not answer
correctly.
187

7.1.2 The exam and the Syllabus
The ISTQB Foundation exam is designed to assess your knowledge and under-
standing of basic testing ideas and terms, which provides a solid starting point for
your future testing efforts. These exams are not perfect. Even well-qualified candi-
dates often fail a few questions or disagree with some answers. Study hard, so you
can take the exam in a relaxed and confident way.
If you take the exam unprepared, you should expect your lack of preparation to
show in your score. Since you
’ll pay to take the exam, consider preparation time an
investment in protecting your exam fee.
The ISTQB Foundation Syllabus 2011 is the current syllabus. It replaces the
2010 version, which in turn replaced the 2007 version, which in turn replaced the
2005 version. Do not refer to the old syllabi, as the exam covers the new Syllabus.
7.1.3 Where should you take the exam?
If you have taken an accredited training course, it
’s quite likely the exam will occur on
the last day of the course. The exam fee may have been included in the course fee. If
so, you should plan to study each evening during the course, including material that
will be covered on the last day. Any topic covered in the Syllabus may be in an exam.
You might even want to read this book before starting the course.
You might be taking an on-line course. Again, we recommend that you study the
materials as you cover each section. Consider reading the book during or even
before taking the course.
If you have studied on your own, without taking a course, then you
’ll need to find a
place open to the general public to take the exam. Many conferences around the world
offer the exam this way. Otherwise the website for the testing board for your country
(the National Board) should be able to help you find the right venue for a public exam.
In addition, the Foundation Certification exam is available in electronic versions;
e.g. via Kryterion, Pearson-Vue, Prometric and other commercial electronic test
centres. This is a real advantage for those who live or work away from those cities
where in-person courses and exams are offered. The price is competitive with the in-
person exam fee, so you won
’t pay a big premium for convenience.
Regardless of which National Board administers the exam, all National Boards
are bound by the ISTQB Constitution to recognize the certification granted. In
addition, ISTQB-recognized Exam Boards such as DLGI, GASQ, ISEB, iSQI and
SAQ will provide you with ISTQB-branded certificates, as they work in close
cooperation with the ISTQB and its National Boards. The ISTQB and each ISTQB-
recognized National Board and Exam Board are constitutionally obliged to support a
single, universally accepted, international qualification scheme. Therefore, you are
free to choose ISTQB-accredited trainers, if desired, and ISTQB-accredited exam
providers based on factors like convenience, competence, suitability of the training
to your immediate professional and business needs and price.
7 . 2
T A K I N G T H E E X A M
All the National Boards offer the same type of Foundation exam. It is a multiple-
choice exam that conforms to the guidelines established by the ISTQB. For some of
us, it
’s been a while since we last took an exam and you may not remember all the
188
Chapter 7 ISTQB Foundation Exam

tricks and techniques for taking a multiple-choice exam. Here are a few paragraphs
that will give you some ideas on how to take the exam.
7.2.1 How to approach multiple-choice questions
Remember that there are two aspects to correctly answering a multiple-choice exam
question. First, you must understand the question and decide what the right answer
should be. Second, you must correctly communicate your answer by selecting the
most correct option from the choices listed.
Each question has one correct answer. This answer is always or most frequently
true, given the stated context and conditions in the question. The other answers are
intended to mislead people who don
’t completely understand the concept, and are
called
‘distracters’ in the examination business.
So, read the question carefully and make sure you understand it before you decide on
your answer. It may help to underline the key words or concepts stated in the question.
Some questions may be ambiguous or ask which is the best or worst alternative. You
should choose the best answer based on what you
’ve learned in this book. Remember
that your own situation may be different from the most common situation.
Some of the distracters may distract you. In other words, you might be unsure about
the correct answers to all of the questions. So, make two passes through the exam. On
your first pass, answer all of the questions you are sure of. Come back to the others later.
If a question will take a long time to answer, come back to it later. For example,
questions that require you to draw flow charts to understand code coverage often
take much longer to answer. Come back to them later when you feel confident that
you have enough time.
It
’s important to pace yourself. We suggest that you spend 45–60 seconds on
each question; that way your first pass will take less than 40 minutes. You can then
use the remaining time to have a one-minute break, then double-check your answers
on the answer sheet, and then finally go back to any questions you have left blank.
The answer sheets for the exams vary slightly from one National Board or Exam
Board to another. However, you should make sure that each answer corresponds to the
correct question number. Especially if you have skipped a question, it
’s easy to get
confused and mark the answer option above or below the question you are trying to
answer. Also, make sure you have an answer for every question. In addition, double-
check that you have selected the answer you want, as it is easy to select the wrong answer.
7.2.2 On
‘trick’ questions
There are no deliberately designed trick questions in the ISTQB exams, but some
can seem quite difficult if you are not completely sure of the right answer. Remem-
ber, just because it
’s hard to answer doesn’t make it a trick. Here are some ideas for
dealing with the tough questions.
First, read the question and each of the options very thoroughly. It is easy to read
what you expect to be there rather than what is there.
If you are tempted to change your answer, do so only if you are quite sure. When
you are vacillating, it is usually best to go with your first instinct. Remember that the
correct answer is the one always or most often true. Simply because you can imagine
a circumstance under which an answer might not be true does not make it wrong, just
as knowing a 95-year-old cigarette smoker does not prove that cigarette smoking is
not risky.
Section 2 Taking the Exam 189

For most exams, you are allowed to write on the question paper. In addition,
there is typically no penalty for the wrong answer. So, feel free to guess!
While the ISTQB guidelines call for straightforward questions, some topics are
difficult to cover without some amount of complexity. Be especially careful with
negative questions and complex questions. If the question asks which is false (or
true), mark them T or F first. This will make it easier to see which is the odd one out.
If the question requires matching a list of definitions, draw lines between the
definitions and the words they define. And remember to put the process of elimina-
tion to work for you whenever possible. Use what you know to eliminate wrong
answers and cross them out up front to avoid mistakes.
Finally, remember that the ISTQB exam is about the theory of good practice, not
what you typically do in practice. The ISTQB syllabus was developed by an
international working group of testing experts based on the best practices they have
seen in the real world. In testing, best practices lead typical practices by about
20 years at this point. Some organizations are struggling to implement even basic
testing principles, such as convincing managers that exhaustive testing is impossi-
ble, while other organizations may already be doing most of the things discussed in
the Syllabus; still other organizations may do things well but differently to what is
described in the Syllabus. So, remember to apply what you
’ve learned in this book
to the exam. When an exam question calls into conflict what you
’ve learned here
and what you typically have done in the past, rely on what you
’ve learned to answer
the exam question. And then go back to your workplace and put the good ideas that
you
’ve learned into practice!
7.2.3 Last but not least
We wish you good luck with your certification exam and best of success in your
career as a test professional! We stand poised on the brink of great forward progress
in the field of testing and are happy that you will be a part of it.
190
Chapter 7 ISTQB Foundation Exam

M O C K E X A M
On the real exam, you will have 60 minutes to work through 40 questions of approximately the same difficulty
mix and Syllabus distribution as shown in the following mock exam. After you have taken this mock exam,
check your answers with the answer key. (The answers to all exam questions in this book are in the section after
the Glossary.)
Question 1 What is a key characteristic of
specification-based testing techniques?
a. Tests are derived from information about how the
software is constructed.
b. Tests are derived from models (formal or informal)
that specify the problem to be solved by the
software or its components.
c. Tests are derived based on the skills and
experience of the tester.
d. Tests are derived from the extent of the coverage
of structural elements of the system or
components.
Question 2 An exhaustive test suite would include:
a. All combinations of input values and
preconditions.
b. All combinations of input values and output
values.
c. All pairs of input value and preconditions.
d. All states and state transitions.
Question 3 Which statement about testing
is true?
a. Testing is started as early as possible in the life
cycle.
b. Testing is started after the code is written so that
we have a system with which to work.
c. Testing is most economically done at the end of
the life cycle.
d. Testing can only be done by an independent test
team.
Question 4 For a test procedure that is checking
modifications of customers on a database, which
of the following two steps would be the lowest
priority if we didn
’t have time to execute all of
the steps?
1 Open database and confirm existing customer.
2 Change customer
’s marital status from single to
married.
3 Change customer
’s street name from Parks Road
to Park Road.
4 Change customer
’s credit limit from 500 to 750.
5 Replace customer
’s first name with exactly the
same first name.
6 Close the customer record and close the database.
a. Test steps 1 and 4.
b. Test steps 2 and 3.
c. Test steps 5 and 6.
d. Test steps 3 and 5.
Question 5 Consider the following list of either
product or project risks:
I
An incorrect calculation of fees might
short-change the organization.
II A vendor might fail to deliver a system
component on time.
III A defect might allow hackers to gain
administrative privileges.
IV A skills gap might occur in a new technology
used in the system.
V A defect-prioritization process might overload
the development team.
Which of the following statements is true?
a. I is primarily a product risk and II, III, IV and V
are primarily project risks.
b. II and V are primarily product risks and I, III and V
are primarily project risks.
c. I and III are primarily product risks, while II, IV
and V are primarily project risks.
d. III and V are primarily product risks, while I, II
and IV are primarily project risks.
Mock Exam 191

Question 6 Consider the following statements about
regression tests:
I
They may usefully be automated if they are well
designed.
II They are the same as confirmation tests (re-tests).
III They are a way to reduce the risk of a change
having an adverse affect elsewhere in the system.
IV They are only effective if automated.
Which pair of statements is true?
a. I and II
b. I and III
c. II and III
d. II and IV
Question 7 Which of the following could be used to
assess the coverage achieved for structure-based
(white-box) test techniques?
V Decision outcomes exercised.
W Partitions exercised.
X Boundaries exercised.
Y Conditions or multiple conditions exercised.
Z Statements exercised.
a. V, W or Y
b. W, X or Y
c. V, Y or Z
d. W, X or Z
Question 8 Review the following portion of an
incident report.
1 I place any item in the shopping cart.
2 I place any other (different) item in the shopping
cart.
3 I remove the first item from the shopping cart, but
leave the second item in the cart.
4 I click the  button.
5 I expect the system to display the first checkout
screen. Instead, it gives the pop-up error message,
‘No items in shopping cart. Click  to
continue shopping.
’
6 I click .
7 I expect the system to return to the main window to
allow me to continue adding and removing items
from the cart. Instead, the browser terminates.
8 The failure described in steps 5 and 7 occurred in each
of three attempts to perform steps 1, 2, 3, 4 and 6.
Assume that no other narrative information is
included in the report. Which of the following
important aspects of a good incident report is missing
from this incident report?
a. The steps to reproduce the failure.
b. The summary.
c. The check for intermittence.
d. The use of an objective tone.
Question 9 Which of the following are benefits and
which are risks of using tools to support testing?
1 Over-reliance on the tool.
2 Greater consistency and repeatability.
3 Objective assessment.
4 Unrealistic expectations.
5 Underestimating the effort required to maintain the
test assets generated by the tool.
6 Ease of access to information about tests or testing.
7 Repetitive work is reduced.
a. Benefits: 3, 4, 6 and 7. Risks: 1, 2 and 5.
b. Benefits: 1, 2, 3 and 7, Risks: 4, 5 and 6.
c. Benefits: 2, 3, 6 and 7. Risks: 1, 4 and 5.
d. Benefits: 2, 3, 5 and 6. Risks: 1, 4 and 7.
Question 10 Which of the following encourages
objective testing?
a. Unit testing.
b. System testing.
c. Independent testing.
d. Destructive testing.
Question 11 Of the following statements about
reviews of specifications, which statement is true?
a. Reviews are not generally cost effective as the
meetings are time consuming and require
preparation and follow up.
b. There is no need to prepare for or follow up on
reviews.
c. Reviews must be controlled by the author.
d. Reviews are a cost effective early static test on the
system.
192
Chapter 7 ISTQB Foundation Exam

Question 12 Consider the following list of test
process activities:
I
Analysis and design.
II Test closure activities.
III Evaluating exit criteria and reporting.
IV Planning and control.
V Implementation and execution.
Which of the following places these in their logical
sequence?
a. I, II, III, IV and V.
b. IV, I, V, III and II.
c. IV, I, V, II and III.
d. I, IV, V, III and II.
Question 13 Test objectives vary between projects
and so must be stated in the test plan. Which one of
the following test objectives might conflict with the
proper tester mindset?
a. Show that the system works before we ship it.
b. Find as many defects as possible.
c. Reduce the overall level of product risk.
d. Prevent defects through early involvement.
Question 14 Which test activities are supported by
test data preparation tools?
a. Test management and control.
b. Test specification and design.
c. Test execution and logging.
d. Performance and monitoring.
Question 15 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 flyer programme. 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 7.1. Note that each box
(i.e. statement) has been numbered.
Three tests have already 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 additional tests would be needed to achieve
100% decision coverage?
a. A gold card holder who stays in economy and a
non-gold card holder who gets upgraded to
business class.
b. A gold card holder and a non-gold card holder who
are both upgraded to business class.
c. A gold card holder and a non-gold card holder
who both stay in economy class.
d. A gold card holder who is upgraded to business
class and a non-gold card holder who stays in
economy class.
Question 16 Consider the following types of tools:
V Test management tools.
W Static analysis tools.
X Modelling tools.
Y Dynamic analysis tools.
Z Performance testing tools.
Which of the following of these tools is most likely to
be used by developers?
a. W, X and Y
b. V, Y and Z
c. V, W and Z
d. X, Y and Z
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 7 . 1
Control flow diagram for flight check-in
Mock Exam 193

Question 17 What is a test condition?
a. An input, expected outcome, precondition and
postcondition.
b. The steps to be taken to get the system to a given
point.
c. Something that can be tested.
d. A specific state of the software, e.g. before a test
can be run.
Question 18 Which of the following is the most
important difference between the metrics-based
approach and the expert-based approach to test
estimation?
a. The metrics-based approach is more accurate than
the expert-based approach.
b. The metrics-based approach uses calculations from
historical data while the expert-based approach
relies on team wisdom.
c. The metrics-based approach can be used to verify
an estimate created using the expert-based
approach, but not vice versa.
d. The expert-based approach takes longer than the
metrics-based approach.
Question 19 If the temperature falls below 18
degrees, the heating is switched on. When the
temperature reaches 21 degrees, the heating is
switched off. What is the minimum set of test input
values to cover all valid equivalence partitions?
a. 15, 19 and 25 degrees.
b. 17, 18, 20 and 21 degrees.
c. 18, 20 and 22 degrees.
d. 16 and 26 degrees.
Question 20 Which of these statements about
functional testing is true?
a. Structural testing is more important than functional
testing as it addresses the code.
b. Functional testing is useful throughout the life
cycle and can be applied by business analysts,
testers, developers and users.
c. Functional testing is more powerful than static
testing as you actually run the system and see what
happens.
d. Inspection is a form of functional testing.
Question 21 What is the purpose of confirmation
testing?
a. To confirm the users
’ confidence that the system
will meet their business needs.
b. To confirm that a defect has been fixed correctly.
c. To confirm that no unexpected changes have been
introduced or uncovered as a result of changes
made.
d. To confirm that the detailed logic of a component
conforms to its specification.
Question 22 Which success factors are required for
good tool support within an organization?
a. Acquiring the best tool and ensuring that all testers
use it.
b. Adapting processes to fit with the use of the tool
and monitoring tool use and benefits.
c. Setting ambitious objectives for tool benefits and
aggressive deadlines for achieving them.
d. Adopting practices from other successful
organizations and ensuring that initial ways of
using the tool are maintained.
Question 23 Which of the following best describes
integration testing?
a. Testing performed to expose faults in the interfaces
and in the interaction between integrated
components.
b. Testing to verify that a component is ready for
integration.
c. Testing to verify that the test environment can be
integrated with the product.
d. Integration of automated software test suites with
the product.
Question 24 According to the ISTQB Glossary,
debugging:
a. Is part of the fundamental testing process.
b. Includes the repair of the cause of a failure.
c. Involves intentionally adding known defects.
d. Follows the steps of a test procedure.
Question 25 Which of the following could be a root
cause of a defect in financial software in which an
incorrect interest rate is calculated?
194
Chapter 7 ISTQB Foundation Exam

a. Insufficient funds were available to pay the interest
rate calculated.
b. Insufficient calculations of compound interest were
included.
c. Insufficient training was given to the developers
concerning compound interest calculation rules.
d. Inaccurate calculators were used to calculate the
expected results.
Question 26 Assume postal rates for
‘light
letters
’ are:
$0.25 up to 10 grams;
$0.35 up to 50 grams;
$0.45 up to 75 grams;
$0.55 up to 100 grams.
Which test inputs (in grams) would be selected using
boundary value analysis?
a. 0, 9, 19, 49, 50, 74, 75, 99, 100
b. 10, 50, 75, 100, 250, 1000
c. 0, 1, 10, 11, 50, 51, 75, 76, 100, 101
d. 25, 26, 35, 36, 45, 46, 55, 56
Question 27 Consider the following decision table.
Given this decision table, what is the expected result
for the following test cases?
TC1: A 26-year-old on business but with violations or
accidents on his driving record.
TC2: A 62-year-old tourist with a clean driving
record.
a. TC1: Don
’t supply car; TC2: Supply car with
premium charge.
b. TC1: Supply car with premium charge;
TC2: Supply car with no premium charge.
c. TC1: Don
’t supply car; TC2: Supply car with no
premium charge.
d. TC1: Supply car with premium charge; TC2: Don
’t
supply car.
Question 28 What is exploratory testing?
a. The process of anticipating or guessing where
defects might occur.
b. A systematic approach to identifying specific
equivalent classes of input.
c. The testing carried out by a chartered engineer.
d. Concurrent test design, test execution, test logging
and learning.
Question 29 What does it mean if a set of tests has
achieved 90% statement coverage?
a. 9 out of 10 decision outcomes have been exercised
by this set of tests.
b. 9 out of 10 statements have been exercised by this
set of tests.
c. 9 out of 10 tests have been run on this set of software.
d. 9 out of 10 requirements statements about the
software are correct.
Question 30 A test plan is written specifically to
describe a level of testing where the primary goal is
establishing confidence in the system. Which of the
following is a likely name for this document?
a. Master test plan.
b. System test plan.
c. Acceptance test plan.
d. Project plan.
Question 31 Requirement 24.3. A
‘Postage
Assistant
’ will calculate the amount of postage due for
letters and small packages up to 1 kilogram in weight.
The inputs are: the type of item (letter, book or other
package) and the weight in grams. Which of the
following conform to the required contents of a
test case?
T A B L E 7 . 1
Decision table for car rental
Conditions
Rule 1
Rule 2
Rule 3 Rule 4
Over 23?
F
T
T
T
Clean driving
record?
Don
’t care
F
T
T
On business?
Don
’t care Don’t care
F
T
Actions
Supply rental car?
F
F
T
T
Premium charge?
F
F
F
T
Mock Exam 195

a. Test the three types of item to post and three
different weights [Req 24.3].
b. Test 1: letter, 10 grams, postage
€0.25. Test 2:
book, 500 grams, postage
€1.00. Test 3: package,
999 grams, postage
€2.53 [Req 24.3].
c. Test 1: letter, 10 grams to Belgium. Test 2: book
500 grams to USA. Test 3: package, 999 grams to
South Africa [Req 24.3].
d. Test 1: letter 10 grams, Belgium, postage
€0.25.
Test 2: package 999 grams to South Africa,
postage
€2.53.
Question 32 What is the best description of static
analysis?
a. The analysis of batch programs.
b. The reviewing of test plans.
c. The analysis of program code or other software
artefacts.
d. The use of black-box testing.
Question 33 System test execution on a project is
planned for eight weeks. After a week of testing, a
tester suggests that the test objective stated in the test
plan of
‘finding as many defects as possible during
system test
’ might be more closely met by redirecting
the test effort according to which test principle?
a. Impossibility of exhaustive testing.
b. Importance of early testing.
c. The absence of errors fallacy.
d. Defect clustering.
Question 34 Consider the following activities that
might relate to configuration management:
I
Identify and document the characteristics of a
test item.
II Control changes to the characteristics of a test item.
III Check a test item for defects introduced by a
change.
IV Record and report the status of changes to test items.
V Confirm that changes to a test item fixed a
defect.
Which of the following statements is true?
a. Only I is a configuration management task.
b. All are configuration management tasks.
c. I, II and III are configuration management tasks.
d. I, II and IV are configuration management tasks.
Question 35 Consider the following state transition
diagram.
Given this diagram, which test case below covers
every valid transition?
a. SS
– S1 – S2 – S4 – S1 – S3 – ES
b. SS
– S1 – S2 – S3 – S4 – S3 – S4 – ES
c. SS
– S1 – S2 – S4 – S1 – S3 – S4 – S1 – S3 – ES
d. SS
– S1 – S4 – S2 – S1 – S3 – ES
Question 36 A test plan included the following
clauses among the exit criteria:
l
System test shall continue until all significant
product risks have been covered to the extent
specified in the product risk analysis document.
l
System test shall continue until no must-fix defects
remain against any significant product risks
specified in the product risk analysis document.
During test execution, the test team detects 430
must-fix defects prior to release and all must-fix
defects are resolved. After release, the customers
find 212 new defects, none of which were detected
during testing. This means that only 67% of
the important defects were found prior to release, a
percentage which is well below average in your
industry. You are asked to find the root cause for the
high number of field failures. Consider the following
list of possible root causes:
I
Not all the tests planned for the significant
product risks were executed.
II The organization has unrealistic expectations of
the percentage of defects that testing can find.
III A version-control issue has resulted in the
release of a version of the software that was
used during early testing.
SS 
S1 
S4 
S2 
S3 
ES
F I G U R E 7 . 2
State transition diagram
196
Chapter 7 ISTQB Foundation Exam

IV The product risk analysis failed to identify
all the important risks from a customer point
of view.
V The product risk analysis was not updated
during the project as new information became
available.
Which of the following statements indicate which
explanations are possible root causes?
a. II, III and IV are possible root causes, but I and V
are not possible root causes.
b. All five are possible root causes.
c. I, IV and V are possible root causes, but II and
III are not possible root causes.
d. III, IV and V are possible root causes, but I and II
are not possible root causes.
Question 37 What is the most important factor for
successful performance of reviews?
a. A separate scribe during the logging meeting.
b. Trained participants and review leaders.
c. The availability of tools to support the review
process.
d. A reviewed test plan.
Question 38 Consider the following statements
about maintenance testing:
I
It requires both re-test and regression test and may
require additional new tests.
II It is testing to show how easy it will be to
maintain the system.
III It is difficult to scope and therefore needs
careful risk and impact analysis.
IV It need not be done for emergency bug fixes.
Which of the statements are true?
a. I and III
b. I and IV
c. II and III
d. II and IV
Question 39 Which two specification-based testing
techniques are most closely related to each other?
a. Decision tables and state transition testing.
b. Equivalence partitioning and state transition
testing.
c. Decision tables and boundary value analysis.
d. Equivalence partitioning and boundary value
analysis.
Question 40 Which of the following is an advantage
of independent testing?
a. Independent testers don
’t have to spend time
communicating with the project team.
b. Programmers can stop worrying about the quality
of their work and focus on producing more code.
c. The others on a project can pressure the
independent testers to accelerate testing at the end
of the schedule.
d. Independent testers sometimes question the
assumptions behind requirements, designs and
implementations.
Mock Exam 197

A N S W E R S T O S A M P L E E X A M Q U E S T I O N S
This section contains the answers and the learning objectives for the sample ques-
tions in each chapter and for the full mock paper in Chapter 7.
If you get any of the questions wrong or if you weren
’t sure about the answer,
then the learning objective tells you which part of the Syllabus to go back to in order
to help you understand why the correct answer is the right one. The learning
objectives are listed at the beginning of each section. For example, if you got
Question 4 in Chapter 1 wrong, then go to Section 1.2 and read the first learning
objective. Then re-read the part of the chapter that deals with that topic.
C H A P T E R 1
F U N D A M E N T A L S O F T E S T I N G
Question Answer
Learning objective
1
A
1.1.3
2
B
1.1.5
3
C
1.1.5
4
A
1.2.1
5
A
1.2.3
6
C
1.4.1
7
B
1.5.1
8
D
1.2.3, 1.3.1 and 1.4.1
C H A P T E R 2
T E S T I N G T H R O U G H O U T T H E
S O F T W A R E L I F E C Y C L E
Question Answer
Learning objective
1
D
2.1.3
2
D
2.1.3
3
B
2.3.1
4
B
2.3.3
5
C
2.3.1
6
D
2.4.3
7
C
2.3.5
8
B
2.3.1
9
A
2.2.1
221

C H A P T E R 3
S T A T I C T E C H N I Q U E S
Question Answer
Learning objective
1
D
3.1.1
2
A
3.3.2
3
D
3.2.2
4
A
3.2.2
5
D
3.2.2
6
B
3.2.2
7
A
3.3.2
8
C
3.1.2
9
C
3.3.1
C H A P T E R 4
T E S T D E S I G N T E C H N I Q U E S
Question Answer
Learning objective
1
D
4.1.1
2
A
4.1.4
3
C
4.1.4
4
A
4.2.1
5
B
4.2.2
6
C
4.3.1
7
D
4.3.1
8
B
4.3.1
9
B
4.3.2
10
C
4.4.2
11
A
4.3.3
12
C
4.4.2
13
C
4.4.4
14
A
4.5.1
15
D
4.5.2
16
B
4.6.1
17
A
4.3.1
222
Answers to Sample Exam Questions

C H A P T E R 5
T E S T M A N A G E M E N T
Question Answer
Learning objective
1
B
5.1.1
2
D
5.1.4
3
B
Section 5.1
4
A
5.2.2
5
C
5.2.7
6
C
5.2.4
7
D
5.2.9
8
A
Section 5.2
9
C
5.3.1
10
B
5.3.2
11
A
5.3.3
12
C
5.4.1
13
D
5.5.1
14
B
5.5.2
15
A
5.5.3
16
A
5.5.5
17
B
Section 5.5
18
D
5.6.1
19
C
Section 5.6
20
A
Cross-section: 5.3, 5.5, 5.6
C H A P T E R 6
T O O L S U P P O R T F O R T E S T I N G
Question Answer
Learning objective
1
D
6.1.1
2
C
6.1.1
3
B
6.2.1
4
A
6.2.1
5
A
6.2.2
6
B
6.3.1
7
D
6.3.2
Answers to Sample Exam Questions 223

C H A P T E R 7
M O C K E X A M
Question Answer
Learning objective
1
B
4.2.2
2
A
Section 1.3
3
A
2.1.3
4
D
4.1.4 and 5.5.4
5
C
5.5.4
6
B
2.3.5
7
C
4.4.2
8
B
5.6.2
9
C
6.2.1
10
C
1.5.1
11
D
3.1.2
12
B
1.4.1
13
A
1.5.2
14
B
6.1.1
15
A
4.4.3
16
A
6.1.3
17
C
4.1.2
18
B
5.2.8
19
A
4.3.1
20
B
2.3.2
21
B
2.3.5
22
B
6.3.3
23
A
Section 2.2
24
B
1.1.5
25
C
1.1.2
26
C
4.3.1
27
C
4.3.1
28
D
4.5.1
29
B
4.4.1
30
C
5.2.1
31
B
4.1.3
32
C
3.3.1
33
D
Cross-section: 1.2, 1.4
34
D
5.4.1
35
C
4.3.1
36
C
Cross-section: 5.2, 5.5
37
B
3.2.3
38
A
2.4.3
39
D
4.3.1
40
D
5.1.2
224
Answers to Sample Exam Questions