ISEB Intermediate Syllabus
ISEB Intermediate Syllabus
ISEB Intermediate Syllabus
Version 1.4
February 2010
Practitioner Certificate
Test Management
Practitioner Certificate
Test Analysis
Intermediate Certificate
ISEB/ISTQB Foundation
Within this generic description some practitioners will specialise in the management of the
testing function, while others will specialise in the practical testing or test analysis role. Each
of these specialisations has its own examination, but both are built on the foundation
provided by the intermediate examination defined in this syllabus. The intermediate paper is
intended to be an examination appropriate to all testing practitioners. It also constitutes a
qualification in its own right. In order to achieve one of the Practitioner Certificates in
Software Testing, a candidate must hold the Foundation Certificate and Intermediate
Certificate. It is recommended that a candidate sit the Practitioner examination no more than
two years after passing the Intermediate level examination. This is to try to ensure that a
candidates knowledge is based upon the published syllabus and terminology.
Entry Criteria
The entry criteria for candidates taking the Intermediate Certificate in Software Testing are as
follows:
AND EITHER
Page 2 of 31
OR
have completed an ISEB accredited training course for the Intermediate Certificate in
Software Testing
Page 3 of 31
each section; second, to guide the proportion of questions in the exam. Course providers
may spend more time than is indicated and candidates may spend more time again in
reading and research. The total time specified is 18 hours of lecture and practical work.
Courses do not have to follow the same order as the syllabus. Courses may be run as a
single module or broken down into two or three smaller modules.
The syllabus contains references to established standards. The use of referenced standards
in the preparation of training material is mandatory. Each standard used must be the version
quoted in the current version of this syllabus.
Terminology Used
Terminology used in this document is from the current version of the ISTQB Glossary of
Testing Terms or from BS 7925-1, BS 7925-2, IEEE Std. 829-1998, and IEEE Std. 610-1990
as appropriate to the specialist topic. Standards override the glossary in cases of conflict.
This syllabus may override both standards and glossary. Versions of standards and glossary
change from time to time; the version current at the time of publication of this syllabus is the
version referred to in this syllabus as the latest version.
Other Syllabuses
Any references to other ISEB syllabuses refer to the latest published version.
Blooms Taxonomy
Learning objectives in this syllabus are given indicators from K1-K6. These are based on
Blooms taxonomy of knowledge in the cognitive domain (ref Taxonomy of Educational
Objectives, Handbook 1 The Cognitive Domain, Bloom et al., New York 1956), and can be
broadly interpreted as follows: K1 Recall; K2 Comprehension; K3 Application; K4
Analysis; K5 Synthesis; K6 Evaluation. Blooms taxonomy is explained in greater detail
in Appendix A, where examples are given. All topics in this syllabus have learning objectives
associated with them, each of which has an associated K level. The language used in this
syllabus mirrors as closely as possible the language used in defining Blooms taxonomy to
provide candidates with consistent pointers to the expected level of knowledge and a
consistent way of expressing that level in words.
Further details and examples of learning objectives are given in Appendix A.
Appendix B contains the rules to which the Practitioner Syllabuses are written.
Appendix C contains references to books and other sources of information to support this
syllabus.
Page 4 of 31
This syllabus is structured into sections relating to major subject headings and numbered
with a single digit section number. Each section is allocated a minimum contact time for
presentation. Learning objectives are identified at the beginning of each section. The K
level for each learning objective is identified at the lowest level of breakdown in the learning
objectives list.
The breakdown of content matches the structure of the learning objectives, so that the
material related to a given learning objective appears in a paragraph bearing the same
numerical reference as that of the related learning objective. The content associated with
each learning objective may include non-examinable explanatory commentary in italics as
well as the examinable content associated with the learning objective.
Change History
Version 1.4
February 2010
Page 26
under the title of Standards, the work standard has been corrected
in IEEE1044 std.
Typo on page 21, 5.1 (ii), line 3. Show hoe changed to Show how
Page 5 of 31
1.
2.
11
11
14
15
17
17
17
5.
4.
8
8
9
9
3.
20
20
20
21
22
24
24
24
25
Page 6 of 31
Learning Objectives
1.1 Review of the Foundation Certificate Syllabus
i.
Recall the main principles and themes from the Foundation syllabus, all of which
are considered part of the required knowledge for this syllabus. (K1)
Recognise and explain the relationship between testing and development (K2)
Identify other processes with which testing interfaces during development (K1)
Explain the relationships between debugging, initial testing during development,
confirmation testing and regression testing (K2)
Explain how testing fits into sequential and iterative life cycle models (K2)
Describe the testing challenges associated with each life cycle and explain how
these challenges can be met (K2)
Analyse a situation to identify the SDLC model(s) in place and select appropriate
testing activities to fit with the situation and the life cycle(s) in place (K4)
Recall the fundamental test process and explain how it may be deployed in
different situations and within different life cycle models (K2)
Page 7 of 31
Introduce the issues, philosophy and key points of software testing as covered in
material based on the current syllabus of the ISEB/ISTQB Foundation Certificate
in Software Testing. Provide an introduction to the ISEB Practitioner Certificates
as the next stage in career development.
In particular, review the following topic areas from the Foundation Syllabus:
-
Explain that the four test levels described are not the only possible levels, nor are they
necessarily all present in any given life cycle.
ii.
For each application domain type recognise the main testing challenges that must
be addressed.
iii.
Page 8 of 31
Explain how the development process can influence the testing process, for
example the object-oriented development paradigm where development makes
testing more difficult because of information hiding.
ii.
Introduce the concept of interfaces between the test process and other
processes, such as project management, configuration management and change
management, software development, technical support and technical writing.
iii.
iv.
Describe how testing fits into different SDLCs: sequential (e.g. waterfall and Vmodel), iterative (e.g. Rapid Application Development (RAD), including DSDM
and agile methods), and others including the use of Commercial Off the Shelf
(COTS) software and constructing software from reusable components.
v.
Identify the main differences between the life cycle approaches from a testing
perspective and explain the challenges that each life cycle presents to the tester.
vi.
Analyse a situation to identify the SDLC model(s) in place and select appropriate
testing activities to fit with the situation and the life cycle(s) in place.
Page 9 of 31
2. Reviews (4 hours)
This section has general applicability and will be assumed as background knowledge for both
the Test Management and Test Analysis syllabuses, and requires practical examples of the
use of reviews. The Test Management syllabus will cover further management issues
relating to reviews.
Learning Objectives
2.1 The Principles of Reviews
i.
ii.
iii.
iv.
v.
Recall the basic review process as defined in the Foundation syllabus (K1)
Explain the value of using source documents in reviews (K2)
Describe possible outcomes from a review (K2)
Recall different roles that may be defined for a particular review (K1)
Recall that reviews may come in a variety of forms and have different objectives
(K1)
Describe how more than one type of review could be used (K2)
Describe the relationship of reviews to dynamic testing (K2)
Analyse organisations and situations to enable the best choice of review type(s)
to be made (K4)
Page 10 of 31
Recall the basic review process defined in the Foundation syllabus and recognise
the IEEE Std. 1028-1997 Standard for Software Reviews. Explain that, while this
syllabus is broadly based on that standard, there is no definitive document that
captures current best practice or recognises the many valid variations of review
practice that occur in organisations. This syllabus identifies key principles and
provides a comparative description of a selection of commonly used review types
in the expectation that these will provide an adequate basis for the evaluation,
selection and effective implementation of appropriate review techniques.
ii.
Recall that reviews are ideally performed when the source documents (those
documents that specify the requirements of the product to be reviewed) and those
standards to which the product must conform are available. Without source
documents, reviews may be limited to finding errors of consistency and
completeness within the document under review.
iii.
iv.
Recall that those involved with reviews often have specific roles and
responsibilities. These may include the author of the product, the scribe, who
records the issues raised at the review meeting, the chair, who runs the meeting,
and the presenter, who leads the meeting through the product. There will often be
other reviewers, who simply review the product. There may be a leader for the
complete review process. Individual reviewers may be required to look for specific
types of issue, and, if so, are often given checklists of issue types to look for.
v.
Recall the various forms of review defined in the Foundation syllabus. Recognise
that the choice of form of review is dependent on the objectives of the review as
well as the culture and maturity of the organisation performing the review.
Page 11 of 31
a) Introduction - The purpose and objectives of a review and the typical work
products for which it may be used; explain that any type of review requires clear
objectives to be defined as an input to the review.
b) Responsibilities - The roles and responsibilities associated with the review;
explain that these need to be defined according to the type of review and the
nature of the source document(s).
c) Input - The necessary inputs to the review; explain that these may vary according
to the type of review.
d) Entry Criteria - The criteria that need to be met before a review can begin;
explain that all review types will have some entry criteria, but the nature of the
criteria will vary by review type.
e) Procedures - Key procedural aspects for a given review; explain how these vary
between the types of review.
f) Exit Criteria - Criteria to be met before a review can be considered complete;
explain the nature of these criteria and how they vary between types of review.
g) Output - Typical deliverables for a review type; explain how these vary for each
type of review.
i.
Compare the different types of formal review and describe their relative strengths
and weaknesses and the situations where each may be applicable.
A. Management Review
Explain that:
a) The purposes of management reviews typically include evaluation of
management activities and the support of management decisions. Typical
products reviewed would include incident reports, risk management plans, test
plans.
b) Management reviews will normally include the decision maker for whom the
review is being conducted.
c) Inputs will typically include information on the status of the product being reviewed
relative to any plan in place for it.
d) Normally management reviews will be scheduled but a review may be held at the
request of a decision maker such as the project manager or test manager.
Objectives for the review will need to be in place before the review is initiated.
e) Reviewers will be expected to prepare for the review by studying the appropriate
documents and providing comments to the decision maker. Rework will be
followed up to ensure timely completion.
f) The review is complete when required outputs have been produced and any
rework has been defined with an agreed delivery date.
g) Output would normally include a record of any errors and planned actions.
B. Walkthrough
Explain that:
a) Walkthroughs are held to identify errors in documents, but a major objective is
commonly to educate reviewers in respect of a project or work product. Source
documents would typically include requirements specifications, test strategies,
test plans and test specifications.
b) Because walkthroughs are often relatively informal and may address a number of
objectives, role assignments may be shared. The author is normally present and
walkthroughs are usually restricted to peer groups.
Copyright BCS 2010
Intermediate Certificate in Software Testing
Version 1.4
Page 12 of 31
c) The main input is the source document. There may be specifications and
standards, but guidelines are often more appropriate.
d) The only entry criterion for a walkthrough would normally be the availability of
source documentation and reviewers.
e) Source documents may be distributed before the meeting. Normally the author
would make an overview presentation, often using scenarios for requirement and
design models and dry runs through code, as a prelude to a general discussion.
Reviewers can raise queries or identify errors during the discussion. Errors are
normally captured at the walkthrough meeting to enable the author to make
corrections after the walkthrough meeting.
f) The walkthrough is considered complete when all reviewers have raised any
questions and/or errors and these have been satisfactorily captured.
g) The list of errors may form output from a walkthrough or the source document
may be marked up for later correction.
C. Technical Review
Explain that:
a) The purpose of a technical review is normally to evaluate a work product to
determine its suitability for intended use and to identify discrepancies from
specifications and/or standards. Typical documents reviewed would include
requirements specifications and test specifications.
b) Reviewers would normally be staff with appropriate technical expertise to evaluate
the source documents. Customer or user representatives or other stakeholders
may be invited to attend with a well defined role.
c) As well as the review objectives and source documents, inputs may include
relevant standards and specifications.
d) Technical reviews will normally be scheduled, but could also be required by
managers, for example to evaluate the impact of incident reports or test results.
e) Thorough preparation is essential for a technical review. Comments should be
returned to the review leader and passed on to the author prior to the review
meeting. The review leader should confirm that preparation has been adequate
before the review begins.
f) The review is complete when the status of the work product is defined and any
actions required to meet required standards are defined.
g) Output from a technical review would include a list of any errors and action items
related to their correction, and a list of any unresolved issues relating to the work
product or any specifications.
D. Inspection
Explain that:
a) The purpose of an inspection is normally to identify and describe errors in a work
product in relation to specifications, standards and expected quality attributes. In
addition, inspections gather data for the purpose of improving the processes used
to create the work product and the inspection process. Typical documents
reviewed would include requirements specifications and test specifications.
b) An inspection is led by a trained inspection leader (or moderator). Other
reviewers (inspectors) are usually selected to represent different viewpoints and
may also be assigned specific review topics (e.g. one may focus on conformance
to specification and another on correctness of the design ).
Copyright BCS 2010
Intermediate Certificate in Software Testing
Version 1.4
Page 13 of 31
c) As well as objectives for the review, inputs normally include appropriate checklists
and rule sets for the inspection.
d) Entry criteria are usually very specific and would be expected to include: the work
product conforms to appropriate standards for content and format; prior
milestones have been achieved; supporting documentation is available.
e) Inspection leaders select inspectors, assign responsibilities and distribute
inspection materials before the initial kick-off or overview meeting, which is held
so that all participants understand their responsibilities and the product and
source documents. At the kick-off, rule sets are identified and inspection rates
assigned before inspectors begin their preparation. Each reviewer inspects the
product individually and reports back on issues raised in a meeting run by the
inspection leader. The meeting focuses on identifying errors, not solving them.
The inspection leader collects statistics about the time spent by each participant
and the errors found and fixed. An exit decision is made at the meeting.
f) An inspection is considered complete when the output has been defined, any
actions have been defined, and required data has been collected.
g) Typical output would be data related to the source document, such as the size of
the document, and any errors identified by the inspection, such as the number of
errors found by category. Data related to the inspection, such as preparation time
and inspection rates would typically also be captured.
h) Explain how one possible outcome of an inspection could be process
improvement by sampling a limited number of pages
i) Explain that inspection principles can be applied in an agile context to maximise
the benefits of the technique for individuals.
ii.
Explain that formality in reviews relates to the following attributes, each of which
may be varied: whether or not a meeting is held; nature of entry criteria; level of
preparation for meetings; definition of roles, checklists and rule sets of meetings;
nature of meetings; extent and nature of output; nature of exit criteria; nature of
follow up. Recognise that reviews may be more or less formal. Informal reviews
will have the basic characteristics of more formal reviews except in the level of
formality. Reviews described in the following subsections relate to formal
reviews. Explain that informal reviews can be used as an entry point for
organisations with no culture of performing reviews and can facilitate the
development of a culture and a discipline that enables more formal review
techniques to be implemented when and where appropriate.
Explain how more than one of the review techniques may be employed on a
single product. For example, an informal review could be conducted for an early
draft of a document, changes could be made as a result of the review, and then a
more formal review type could be performed. Compare and contrast the
effectiveness of the different review types and identify suitable hybrid types or
combinations that would suit particular circumstances. Explain that, in any given
situation, a particular type of review, or a sequence of reviews, as described in
this syllabus (or as modified by an organisation) will be most appropriate to the
specific needs of the situation. Recognise that the ability to make a rational
selection, and to identify how the characteristics of the selected review type match
the needs of the situation, will determine the effectiveness of the review.
Recognise that reviews in real organisations may not be either named or used
exactly as described in this syllabus, but that the characteristics and principles
described in this syllabus can be used to evaluate the effectiveness of the actual
reviews used by an organisation.
Page 14 of 31
ii.
Explain why, when reviews are used on code, they should normally be followed
by dynamic testing, which can find those types of error that cannot easily be found
by static testing.
iii.
ii.
Analyse the value of the particular type of formal review performed (for example
by measuring the time and effort expended for each error found) and draw
conclusions about the potential effectiveness of other review types in a similar
situation.
Page 15 of 31
Learning Objectives
3.1 Introduction to Risk
i.
ii.
iii.
Recall the nature of product risk and project risk and their effects. (K1)
Explain how risks can interact with other risks. (K2)
Describe typical risks associated with given application domains. (K2)
ii.
Recall the core activities of risk management: risk identification, risk analysis and
risk mitigation and explain the importance of achieving maximum stakeholder
involvement in these activities. (K2)
Explain the relationship between risk and testing. (K2)
Page 16 of 31
Review the definition of risk and the difference between project and product risks.
Explain that project risks primarily affect the successful completion of the project
(e.g. extend the delivery timescales) and are addressed by project management
actions. Explain that product risks primarily impact the product (e.g. a software
failure that takes the delivered system out of operation) and are important drivers
of testing strategy.
ii.
Explain that project risks and product risks will affect each other: a project risk, by
causing delay, may impact on the quality of work and so lead to additional product
risk; a product risk (e.g. a complex design) may cause extra testing to be
incorporated, leading to delay and associated project risk.
iii.
Describe typical risks (both product and project) to be considered such as those
related to safety, economic, security, political and technical factors and give
examples of each of these. Relate risks to application domains and identify
typical risks to be expected in a given domain.
Project risks and risk mitigation will be covered in more detail in the Test Management
syllabus.
Explain that ideally all stakeholder groups should be directly involved at all stages
of risk management.
ii.
Give examples of how project and product risks can be addressed by decisions
documented in the test strategy, such as which test levels to include, and which
test case design techniques and test exit criteria to use.
Identify product risks that could be addressed by testing (e.g. a risk of slow
response times could be addressed by performance testing).
ii.
Page 17 of 31
Learning Objectives
4.1 Test Policy, Test Strategy, Test Plans
i.
ii.
iii.
Explain the significance of objective test entry and exit criteria (K2)
Give examples of suitable test entry and exit criteria and explain possible
alternative courses of action when test entry and exit criteria are not met (K2)
Analyse testing situations to select appropriate test entry and exit criteria (K4)
iii.
iv.
v.
vi.
iv.
Describe how testing may be monitored, and give examples of what could be
monitored (K1)
Identify and describe typical measures of test progress and test quality (K2)
Identify the content of test summary reports appropriate to a range of
stakeholders and at different stages of the test process and at different points in
the life cycle (K2)
Analyse a test summary report to assess the testing reported on and decide on
required control actions (K4)
Page 18 of 31
Describe how incidents are reported, tracked and analysed to ensure that
remedial action is effective (K2)
Describe alternative incident management processes (K2)
Analyse a simple incident management process and determine what
improvements could be made (K4)
Page 19 of 31
ii.
Identify the relationships between the various levels of document and explain the
purpose of each level. Explain that there are alternative ways to document test
management information and that documents will not necessarily have the names
used in this syllabus.
iii.
Explain the concept and purpose of overall test project entry and exit criteria
(sometimes known as acceptance criteria or test completion criteria), and of entry
and exit criteria for test levels. Explain the difference between test entry and exit
criteria, including the possibility that, as well as exit criteria from the previous test
level, entry criteria may depend on factors such as the availability of a test
environment for the phase being entered.
ii.
Give examples of typical test entry and exit criteria, and explain what alternatives
are available when they are not met, and explain that the alternatives depend on
the organisations approach to risk management and on overall organisational
(test) policy.
iii.
Analyse testing situations and select appropriate test entry and exit criteria to
meet defined objectives.
ii.
Estimates should take account of dependent activities, such as the elapsed time
for fixing defects found in test execution, and the time and effort needed for
subsequent confirmation testing and regression testing.
iii.
Page 20 of 31
Explain that deadlines represent targets that are desirable for political or
commercial reasons, but estimates are based on a given scope of work.
v.
Explain that several cycles (or iterations) of running tests will normally be required
(run tests, report defects, confirmation tests, running of any tests that were not
able to be run in the first cycle, and regression testing).
vi.
Analyse testing situations to determine the best estimating approach and make
estimates of required test effort and duration, including estimates of expected
levels of confirmation and regression testing.
Explain that testing is monitored in order to compare progress with plans. Typical
elements that may be monitored include:
test preparation work completed (compared to planned work)
tests run versus the planned test set
result of completed tests (pass/fail) versus planned tests
number of incident reports raised, and ranked by severity and priority
time and/or effort taken to perform test activities (e.g. setting up a test
environment)
coverage of the system or software by tests run
ii.
Identify and describe typical measurements used to quantify test progress and
test quality, including measures of defect density and the capture of defect trends,
for example by drawing graphs of test activity shown against a time line. Factors
affecting the testing activities should be reported, such as a test environment not
being available, confirmation tests failing, or more defects found than expected.
Describe how information and metrics from test monitoring may be used for test
process improvement.
iii.
Describe the typical contents of a test summary report from a tester to a test
leader/test manager for different test levels and different SDLCs.
iv.
Analyse a test summary report to identify the quality and completeness of testing
reported on.
Page 21 of 31
ii.
Describe mechanisms for tracking and analysing incidents and explain the
importance of ensuring that all incidents are tracked until some resolution is
achieved. Identify alternative resolutions for an incident. Give examples of
tracking mechanisms (e.g. a spreadsheet or a defect tracking tool).
iii.
Page 22 of 31
Learning Objectives
5.1 Fundamentals of Test Analysis
i.
ii.
Identify and explain the principles behind determination of test environment needs
for executing tests (K2)
Analyse a situation to determine test environment requirements (K4)
ii.
iii.
iv.
v.
Explain the concept of coverage and recognise and define suitable measures of
coverage (K2)
Explain the importance of defining what coverage measures mean in a practical
situation (K2)
Analyse a practical testing situation and select appropriate coverage measures
(K4)
Page 23 of 31
Explain the typical activities of test analysis as including: analysis of test basis
documents; generation of test conditions; determination of suitable test cases;
creation of test procedures, and explain that test analysis includes the selection of
the most suitable test design techniques and their effective deployment and the
use of appropriate measures to quantify completeness of testing.
ii.
Explain the nature and purpose of a test environment and give examples where
complex test environments may be needed and will need to be planned early in
the life cycle (e.g. testing of an interactive system intended for continuous
operation in an organisation with offices in several continents).
ii.
Explain the nature and purpose of static testing and dynamic testing. Describe
where each can be used in the life cycle and how they can complement each
other. Give examples of each. Explain the advantages and disadvantages of
scripted testing over unscripted testing (e.g. ad hoc or exploratory testing) and
give examples of situations where each would be the preferred approach.
Describe how the approaches are complementary to each other and how they can
be effectively combined.
Dynamic testing, scripted testing and unscripted testing will be developed in greater detail in
the Test Analysis syllabus.
ii.
Explain the role and purpose of test design techniques and recall the categories
of techniques that are available: specification-based, structure-based and
experience-based.
iii.
Identify and explain typical criteria that should be applied when selecting test
design techniques for a test effort.
iv.
Describe the main benefits of using test design techniques and the main pitfalls in
implementing test design techniques in a project.
v.
Analyse a test basis for an application and select suitable combinations of static
and dynamic testing, scripted and unscripted testing, and test design techniques.
Page 24 of 31
Explain the principle of coverage measurement and show how it can be used to
define an objective exit criterion for testing. Give examples of alternative
coverage measures at each test level (e.g. statements or decision outcomes at
component level, requirements coverage at user acceptance testing level).
Explain that coverage measures can be applied to functional, non-functional and
structural testing. Describe how tests are derived by identifying functional nonfunctional or structural items not yet tested (covered) by a test suite, and explain
that test design is normally done to increase coverage of the software or system.
Explain the role of static analysis in providing structural data from which to derive
structural tests.
Explain the need for appropriate mechanisms, such as
instrumentation, to enable achieved coverage to be measured at test execution.
Identify measures with respect to test progress and completeness, such as test
completion percentage (tests run / tests planned to be run) and test success
percentage (tests that pass / tests run). See also Section 4.4 Test Monitoring.
Explain that the term test coverage is sometimes used inappropriately to refer to
percentages of tests completed as well as to code or system coverage
percentages.
ii.
iii.
Analyse a test basis for an application and select appropriate coverage measures
for use at different test levels within the project.
Page 25 of 31
Can explain the similarities and differences between integration and system testing:
Similarities: testing more than one component, and can test non-functional aspects.
Differences: integration testing concentrates on interfaces and interactions, and
system testing concentrates on whole-system aspects, such as end to end
processing.
Page 26 of 31
Can design a quality risk analysis process that includes both rigorous and informal
elements.
Can create a blended test strategy that uses a dynamic strategy to balance an
analytical strategy.
Can combine aspects of different review processes to form an effective process for
their organisation.
Can determine the relative effectiveness and efficiency of different review processes
or different testing techniques.
Can determine the type of information that should be gathered for an incident report.
References
(For the cognitive levels of learning objectives)
Bloom, B. S. (1956). Taxonomy of Educational Objectives, Handbook I: The Cognitive
Domain, David McKay, Co. Inc.
Anderson, L. W. and Krathwohl, D. R. (eds) (2001). A Taxonomy for Learning, Teaching, and
Assessing: A Revision of Bloom's Taxonomy of Educational Objectives, Allyn & Bacon.
Page 27 of 31
Page 28 of 31
Syllabus References
SR1 Sources and references should be given for concepts in the syllabus to help training
providers find out more information about the topic.
SR2 Where there are not readily identified and clear sources, more detail should be
provided in the syllabus. For example, definitions are in the Glossary, so only the terms are
listed in the syllabus.
Page 29 of 31
www.iseb.org.uk
www.istqb.org
Standards
IEEE 1028 (1998), Standard for Software Reviews, IEEE Standards Board
ISO/IEC 12207 (1995), Information Technology Software Life Cycle Processes
[IEEE 829] IEEE Std 829 (1998/2005) IEEE Standard for Software Test Documentation
(currently under revision)
[ISO 9126] ISO/IEC 9126-1:2001, Software Engineering Software Product Quality
[IEEE 1044] IEEE Std. 1044-1993, Standard Classification for Software Anomalies, IEEE
Std. 1044.1-1995, Guide to Classification for Software Anomalies.
[BS 7925-1] BS 7925-1:1998, Software Testing Part 1: Vocabulary
[BS 7925-2] BS 7925-2:1998, Software Testing Part 2: Software Component Testing
[IEEE 610] IEEE Std 610 (1990), IEEE Standard Computer Dictionaries
Books
Note that these may not be directly referenced in this Syllabus, but represent a selection of
published works that support the principles given in this Syllabus.
[Bach] James Bach (2004), Exploratory Testing, in: Erik van Veenendaal, The Testing
Practitioner 2nd edition, UTN Publishing, ISBN 90-72194-65-9.
[Beizer] Beizer, Boris (1990) Software Testing Techniques (2nd edition), Van Nostrand
Reinhold: Boston.
[Black, 2001] Black, R. (2001) Managing the Testing Process (2nd edition), John Wiley &
Sons: New York.
[Black, 2004] Black, R. Critical Testing Processes, Addison Wesley: Reading MA.
[Copeland] Copeland, Lee (2004) A Practitioners Guide to Software Test Design, Artech
House: Norwood, MA.
Page 30 of 31
[Craig] Craig, Rick D. and Jaskiel, Stefan P. (2002) Systematic Software Testing, Artech
House: Norwood, MA.
[Drabick]Drabick, R., Best Practices for the Formal Software Testing Process: A menu of
Testing Tasks, Dorset House.
[Freedman and Weinberg] Daniel Freedman and Gerald Weinberg (1990), Walkthroughs,
Inspections, and Technical Reviews, Dorset House Publishing, ISBN 0-932633-19-6.
[Gerrard] Paul Gerrard and Neil Thompson (2002), Risk-Based E-Business Testing, Artech
House Publishers, ISBN 1-58053-314-0.
[Gilb and Graham] Tom Gilb and Dorothy Graham (1993), Software Inspection, AddisonWesley, ISBN 0-201-63181-4.
[Hambling] Brian Hambling (Ed.), Peter Morgan, Angelina Samaroo, Geoff Thompson, Peter
Williams (2006), Software Testing: An ISEB Foundation, British Computer Society, Swindon.
[Hetzel] William (Bill) Hetzel (1988), The complete guide to software testing 2nd edition,
QED Information Sciences, ISBN 0-89435-242-3.
[Kaner] Kaner, Cem, Bach, James and Pettticord, Bret (2002) Lessons Learned in Software
Testing, John Wiley & Sons.
[Perry] Perry, W E and Rice, R W., (1997) Surviving the Top-Ten Challenges of Software
Testing: A People Oriented Approach Dorset House.
[Myers] Glenford Myers (1979), The Art of Software Testing, 2nd Ed., Wiley, ISBN 0-47146912-2.
[TMap] Martin Pol, Ruud Teunissen, Erik van Veenendaal (2002), Software Testing, A guide
to the TMap Approach, Addison Wesley, ISBN 0-201-745712.
[Veenendaal] Erik van Veenendaal (2004), The Testing Practitioner 2nd edition, UTN
Publishing, ISBN 90-72194-65-9.
Page 31 of 31