. 9
( 10)


who documents the results of the workshop. The workshop is administered by
a facilitator who, in addition to chairing the session, is responsible for ensuring
all project issues are identi¬ed, reviewed, and re¬ned;
any political issues are identi¬ed and resolved; and
the views of users and developers are given equal weight.

The deliverables from a JAD workshop are a set of documented business require-
ments, which may also contain information on priority and timescales of the
Appendix A. The Principles of Rapid Application Development

documented requirements. A key testing output from a JAD is the test plan (or
the amended test plan in subsequent JADs).

Clean rooms “ JAD workshops are convened at locations away from the customer
and developer sites to ensure that there are no interruptions or distractions that
might compromise the success of the workshop. The location should be selected
to encourage good communication and focused problem solving and should be
equipped with appropriate support facilities such as whiteboards, notepads and
pens, computers, and plentiful supplies of caffeine. Attendees should be strongly
encouraged to switch off mobile phones and avoid doing email for the duration
of the workshop.

A.4 Rapidity of Development
Completing projects on time, within budget, and to acceptable levels of quality is
RAD™s raison d™ˆ tre; as such, RAD projects can be characterized as having short
timescales (particularly with respect to earlier development methods such as water-
fall projects), employing rigorous project management techniques, and ensuring
that automated tool support is considered wherever possible:

RAD timescales “ RAD projects can be characterized as being of relatively short
duration, with two to six months considered the norm, and of no more than six
person-years™ effort in total. The RAD philosophy is that projects taking more
than six months to complete are likely to have been overtaken by developments
in the business (due perhaps to changes in legislation, competitive pressures,
or changes in technology). Smaller, more focused development timescales also
mean that projects are less likely to suffer from time and cost overruns, since
it is easier to assess progress accurately and to identify risks and mitigate them
before they can cause a serious threat to the project success.
Time boxing “ Time boxing [17] is a project management technique in which a
series of development and testing tasks are planned to be completed in a ¬xed
time period or time box; the deadline for the time box is set in stone and cannot
be moved “ even if it is clear that some aspect of the system functionality planned
to be implemented within that time box cannot be completed.

Time boxing relies on the awareness of the priorities documented during the
course of the RAD project to work (typically through user and developer discussion
in JAD workshops); when timescales are tight, the least important features are
sacri¬ced to ensure that development still meets the deadline. Testing effort and
timescales must be included in the time-box planning process to ensure adequate
testing is completed.
Rapid development tools “ RAD encourages the use of automated development
tools in projects wherever it is appropriate and whenever they can be shown
to save time, reduce effort, and save cost. Such tools can include requirements
Appendix A. The Principles of Rapid Application Development

elicitation and management tools such as [61], development tools such as [7],
testing tools such as [62], and con¬guration and change management tools such
as [88]. Where the effort involved in acquiring, rolling out, using, and maintaining
such tools outweighs the savings in terms of time and effort, their use must be

Given the iterative nature of RAD development, testing tools have an important
part to play in terms of saving time, effort, and cost through the reuse of automated
test scripts created during earlier iterations for continuous regression testing in
subsequent iterations.

A.5 Incremental Prototyping
The development of incremental prototypes is core to the success of RAD; simpli-
¬ed working models of the system are constructed and then demonstrated to the
customer representatives. The choice of features implemented in the prototype is
determined by the priorities agreed in discussion with the customer representatives,
and, although built quickly, the prototype is intended to provide the customer with a
representative view of the look, feel, and functionality of the features implemented.
Once the prototype has been completed, the developers test the prototype using test
scripts developed during the earlier design stages.
The customer representatives are able to discuss their perceptions of the proto-
type with the developers, and agree on and document any changes they may feel nec-
essary. After making any required changes to the prototype, the process is repeated.
Within the constraints of project progress and time-box deadlines, this cycle may be
repeated a number of times to ensure the customer representatives are satis¬ed with
the prototype and that the developers are con¬dent that they understand what the
customer is looking for.
From a quality perspective, prototyping has two key bene¬ts:
Customer representatives are exposed to early versions of the system and can
provide immediate feedback on the suitability of the system to the developers.
The prototypes can be used to manage the expectations of the customer in terms
of the ¬nal delivered system, ensuring that there are no last-minute surprises for
the customer that might result in potentially costly rework to the system.

Prototyping can be successfully used throughout the project from requirements
elicitation, design, implementation, testing, and on through to delivery.

The Rules and Practices of Extreme Programming
Its OK to be agile about your agile adoption.
David Evans

B.1 Introduction
This appendix reviews the essential rules and practices of Extreme Programming1
(XP), focusing in more detail on the quality aspects of the method.
The XP rules and practices are grouped into four sections: (1) planning, (2) de-
signing, (3) coding, and (4) testing. It is notable that in virtually every description
of the principles of XP you read, you will ¬nd that testing is covered last. In this
appendix, testing is covered as the ¬rst topic.

B.2 Testing
Quality assurance (QA) is considered to be an essential aspect of XP. QA may be
performed by a separate group, or it can be integrated into the development team
itself. In either case, XP promotes the idea that the developers have a high degree
of contact with the QA group; this is very much in line with the XP philosophy of
closer communications between the stakeholders in a project.
XP provides some excellent guidance on testing:

XP encourages early and frequent testing.
XP looks to make the process as ef¬cient and effective as possible by promoting
the use of test automation.
XP demands that all code have associated tests, and that where code is changed
that the tests be rerun (and/or modi¬ed where appropriate to re¬‚ect the changes).
XP requires test design to be completed before coding has started, with all code
having associated unit tests.
1 Extreme verses eXtreme; although both forms can be found in the literature, for consistency, I have
opted for Extreme. Sincere apologies to anyone who prefers eXtreme and who is seriously offended by
this choice.

Appendix B. The Rules and Practices of Extreme Programming

There are just two types of test in XP:

Unit tests written by the developers to test their code. These are white box tests
[4], which rely on the knowledge of the code and its purpose.
Acceptance tests written with the help of the customer and the user stories, to
validate some expected result from the system. These are black box tests [4], which
are created using the user stories as well as direct user input where available.

The use of test automation in XP is promoted to help save time, effort, and cost of
testing. In addition to ¬nding defects and verifying requirements, the testing tool
can be used at both unit and acceptance testing.
The testing rules and practices of XP state the following:

All code must have unit tests. All classes in the software under development must
have associated tests that are released into the code base alongside the code they
test. Code that is found without a corresponding test cannot be released, and the
unit test must be created as soon as possible to test the software.
All code must pass unit tests before the code can be released. A unit test
framework (such as JUnit [50]) is an essential tool that should be used through-
out the development and testing process to help test, as well as be used to
formalize requirements, re¬ne architecture, write, debug, integrate, release, and
optimize code. It is possible to write your own unit test framework, but this must
be balanced against the productivity gains that reusing a commercial or share-
ware product can deliver.
In XP, unit tests support the concept of collective code ownership; the unit
tests act as a gatekeeper against accidental and deleterious changes to your code
functionality. Since all code must pass unit tests before it can be released, there
is good con¬dence that the code satis¬es its required functionality, irrespective
of who has worked on it.
In principal, this is an excellent agile best practice; implemented properly, it
means that all code that resides in the code base has been validated by speci¬c
tests written against the speci¬cation/requirements/user story2 for that code.
If only this were true for all components found in more traditional software
development projects, there would be much higher con¬dence in the quality of
the software components, with a corresponding simpli¬cation in the execution
of the later testing phases.
Tests must be designed before coding begins. This is an excellent best practice that
ensures that the developers review the requirements for the software, understand
them suf¬ciently well to have a clear idea of how they will be tested, and then
design and implement the unit tests.
It is claimed that the overall time taken to create the unit test and write code
is equivalent to the time taken to just code the software from scratch “ plus you
2 Analogous to use cases.
Appendix B. The Rules and Practices of Extreme Programming

have a set of tests ready to run against the code “ saving additional time and
As a ¬nal thought, it is almost a development and testing clich´ that coding
always overruns and eats into the time planned for testing; create the tests before
coding begins and you have a much higher chance of ensuring that proper testing
will take place.
When a bug is found, tests are created. In the event that a defect is found in
production, tests are created to ensure that, once ¬xed, the defect remains ¬xed;
the tests can be reused to ensure the defect does not reappear at a later point in
the development process.
Working with the customer and the appropriate user story to develop an
acceptance test, the programmer gains a better understanding of the nature of
the defect as well as of the correct behavior the code should exhibit.
In the event that an acceptance test has failed, the programmer creates a unit
test to show the defect from the source-code perspective; once the unit tests are
all executed successfully, the corresponding acceptance test is rerun to ensure
the defect has been ¬xed properly.
Acceptance tests are created from user stories, the tests are run frequently, and
the result is published “ the acceptance tests are based on the user stories created
in conjunction with the customer representative.
During the iteration planning meeting for each iteration, a number of user
stories are selected as the basis of the acceptance tests. A given user story may
result in one or more acceptance tests (the number being determined by what is
needed to show the system performs as expected); each acceptance test represents
some expected result from the system.
The customer is responsible for reviewing the acceptance tests to ensure they
are correct. The customer is also responsible for reviewing the test results and test
scores to identify which failures of the system are most important and specifying
the priority for remedial work, with the developers scheduling the time at each
iteration to correct any failed tests.
Any given user story is not considered complete until it has passed all of its
acceptance tests.

B.3 Planning
The planning rules and practices of XP include the following:

User stories “ are written by the customers as descriptions of things that the
system needs to do for them. They are also used to create time estimates for
release planning and as the basis of creating the acceptance tests.
Release planning “ a release planning meeting is used to create a release plan for
the project, with individual iteration plans based on the release plan schedule.
Appendix B. The Rules and Practices of Extreme Programming

Developer and customer discuss and agree to the order in which the user stories
are to be implemented.
Make frequent small releases “ the development team will release iterative ver-
sions of the software to the customers on a frequent basis. These releases are
determined by decisions made during the release planning meeting about units
of functionality that re¬‚ect useful business activities that can be delivered to the
customer as early as possible within the project timescales.
Project velocity “ the project velocity is a measure of how much work is being
completed on the project. The metric is easy to calculate “ simply add up the
estimates of the user stories that were ¬nished during the iteration. Used in
conjunction with the sum of the tasks ¬nished in the iteration, this information
is used for future iteration planning.
Iterative development “ an iterative approach to development promotes agility in
the development process. By dividing the overall development schedule into about
a dozen smaller units of up to three weeks in length (and keeping the duration
of each iteration the same), development will follow a regular and predictable
rhythm. By following this approach, the task of estimating progress and planning
becomes more simple and more reliable.
Iteration planning “ an iteration planning meeting is called at the beginning of
each iteration to produce that iteration™s plan of programming tasks. User stories
are chosen for this iteration by the customer from the release plan in order of
the most valuable to the customer ¬rst. Where implemented user stories have
failed their acceptance tests in the previous iteration, these can also be selected
for rework and retest, as long as the total amount of effort does not exceed the
project velocity from the previous iteration.
Move people around “ to avoid bus-count problems,3 move people around within
the project to avoid serious knowledge bottlenecks. If only one person on your
team can work in a given area and that person leaves or you just have too
many things waiting to be done in that section, project progress will suffer. Pair
programming makes this approach more practical since typically it is possible to
swap individuals in a pair out to other tasks (and other staff in) without major
impact on productivity.
Daily stand-up meeting “ ensuring good communication among the entire team
is a key aspect of XP. Each morning, the project team stands in a circle to review
problems, discuss solutions, and promote team focus. A goal of the stand-up
meeting is to reduce the need for other meetings that might take place during
the day, helping to focus people™s minds on making progress and saving potential
lost effort.

3 Heaven forbid, but bus-count refers to the number of staff in your project that could be hit by a
bus without there being a signi¬cant impact on project success. It is a measure of the amount of
key knowledge tied up in too few people in a project. Also known as “truck count” in the United
Appendix B. The Rules and Practices of Extreme Programming

Fix XP when it breaks “ XP does not assume that it will have the answers to
all software development projects; in fact it assumes that it won™t. Projects are
encouraged to always start by following the XP rules but not to hesitate to
change any aspect of the approach that does not seem to be working within a
given project. Where deemed necessary, such changes must be fully discussed,
agreed on, and communicated before being implemented.

B.4 Designing
The design rules and practices of XP include:

Simplicity “ complexity is the enemy of progress; a simple design is easier and
quicker to complete. XP challenges developers to seek out the most simple
(and often most elegant) means of satisfying the needs of the system they
are involved in developing. Another guiding principle of simplicity is not to
be tempted to add functionality ahead of when it is scheduled.
Choose a system metaphor “ it is essential that all members of the development
team follow a common vision of how the program works, adopting a common
naming convention and using a common vocabulary. This can be achieved by
adopting and being guided by an appropriate metaphor for the way the system
works; for example, a nest of leaf-cutting ants might be employed as a metaphor
to represent an agent-based Internet-search program, with individual agents (the
ants) sent out to search across the information superhighway (the branches of
the tree) for speci¬c information or pages (the leaves).
Use CRC cards for design sessions “ Class, responsibilities, and collaboration
(CRC) cards [106] encourage the project team to avoid thinking in a procedural
manner and to enable the team to make full use of the object-oriented develop-
ment model. CRC cards are also a powerful means of involving as many of the
project team to contribute to the design as possible; the more people involved,
the more good ideas are incorporated in the design.
Create spike solutions to manage risk “ a spike solution is a simple program
used to investigate possible solutions to a potentially risky aspect of the project.
The spike focuses exclusively on the issue under examination, such as a speci¬c
technical risk or equivocal user story estimate. Once the spike has served its
purpose, it is typically discarded (very few such solutions make it into the released
No functionality is added early “ focus on what is scheduled today; it is always
a temptation to elaborate your code, to add extra code, or to make the existing
code more intricate. Some metrics suggest that only 10% of this additional code
will have any use in the delivered system “ ergo, you will have wasted 90% of the
time in unnecessary effort.
Refactor whenever and wherever possible “ refactoring (taken from the title
of Martin Fowler™s book Refactoring: Improving the Design of Existing Code
Appendix B. The Rules and Practices of Extreme Programming

[56]) is a powerful technique for re¬ning the design and implementation of the

B.5 Coding
The coding rules and practices of XP include the following:

The customer is always available “ this is a key requirement of XP. In practice,
the customer should become part of the development team, ideally co-located
with the other team members but at least available at all times for communica-
tion purposes. The customer is encouraged to actively assign one of their staff
members to the XP project who is expert in the business activity the software
is being developed to address, and who is able to develop the user stories, agree
on timescales, and assign priorities. The customer is also able to review progress
on the developed software and see the working code as it becomes available
(ensuring the delivered code meets expectations).
Code must be written to agreed standards “ developed code must meet agreed
coding standards. Such standards ensure the developed code is consistent and
easy to understand and refactor (see [57], for example).
Code the unit test ¬rst “ creating the unit test before writing the code allows the
developer to focus on what the code needs to do and how to show that it does it;
requirements are reviewed in detail, identifying any potential misunderstanding
or errors in the speci¬cation. All of this is essential work that would have had to
be done before writing code in any case; having the tests available on completion
of the code means tests can be run immediately, allowing bugs to be quickly
identi¬ed and ¬xed and ensuring that development keeps in step with the plan.
Close contact with the customer ensures the tests are realistic and match what
they expect of the software, as well as managing their expectations of what the
delivered software will do.
XP practice says that designing unit tests before code development has begun
makes it much easier and faster to develop the code. It has been claimed that
the additional focus on the requirements and the intended purpose of the code
needed to generate good tests, enable the developer to write the code and test it
faster than the code that could be developed from scratch without any thought
about testing [107].
It is also claimed that there are additional bene¬ts from this approach to
the overall system design. Compared with development approaches that lead to
tests being designed and executed after the software has been implemented (and
often by a separate team of dedicated testers), by developing the tests ¬rst as XP
advocates, the design is in¬‚uenced by the goal of testing those aspects of the
software that are important to the customer, hence leading to an overall design
that is easier to test.
Appendix B. The Rules and Practices of Extreme Programming

All production code is pair programmed “ all code is written by two developers
working together at the same workstation. Having two developers may seem
wasteful in terms of resources, but experience shows that two heads are better
than one (or even two separate heads) at producing higher-quality code in equiva-
lent (or even shorter) timescales than two separate developers. This improvement
in quality of the developed code also leads to savings toward the end of the project,
with reductions in defect detection and reworking of the software.
Code integration “ where a number of developers are working on separate aspects
of the system in parallel, the results of their work should only be integrated
sequentially (and where there are more than two parallel threads, in turn). This
solves the chaos and uncertainty of bringing multiple parallel development
threads together in one go, trying to resolve the inevitable multiple collisions in
the code that such activity typically brings. It is essential that the corresponding
tests (as embodied in the unit test suite) are treated in exactly the same manner.
Integration should be done on a frequent basis to ensure that all the developers
are able to work with the most up-to-date version of the software. As a key
principle, the longest period that coding should continue without integration
is one day. In parallel, good communications between developers is essential to
ensure everyone is aware of what code can be reused or shared.
Use collective code ownership “ using this approach, everyone involved in the
development project is seen as a stakeholder in delivering the system. This means
that everyone involved is encouraged to contribute ideas to the development effort
at any point in the project. In practice, this means developers are allowed to edit
code that they may not have originally written to correct a defect, add function-
ality, or refactor. Although this sounds haphazard, following any changes, the
software must still pass the tests written for that aspect of the system.
Leave optimization until last “ this is an inevitable consequence of following
the aforementioned development rules; with the overall development continuing
in parallel, with frequent integration and testing, and with the frequent ad hoc
changes to the code that collective code ownership brings, it only makes sense to
try to optimize the system once it has begun to achieve some level of stability. A
common mantra of XP is “make it work, make it work right, then make it fast.”
No overtime “ it is one of IT™s best known clich´ s that testers end up with no
social life “ chained to a workstation, probably in a subterranean of¬ce with no
windows, working on into the evening or weekend trying to play catch-up with
the pitiful timescales the late delivery of the code from the developers has left
us with! The result? Tired, resentful staff whose concentration, creativity, and
motivation is inevitably compromised.
XP advocates the use of a release planning meeting to modify the project
timescales and/or the scope of the deliverable to ensure overtime is avoided.
Maintaining good communications with the project stakeholders, and partic-
ularly with the customer, should make this process more straightforward to

The Principles of the Dynamic Systems Development Method
We have no plans, therefore nothing can go wrong.
Spike Milligan

C.1 Introduction
This appendix reviews the essential principles and practices of the Dynamic Systems
Development Method (DSDM) and focuses in more detail on the quality aspects of
the method.
Speci¬cally, this appendix reviews and discusses

the Quality Aspects of DSDM,
the Fundamental Principles and Assumptions of DSDM,
the DSDM Phases and Stages,
DSDM Roles and Responsibilities, and
DSDM Techniques.

C.2 The Quality Aspects of DSDM
One of DSDM™s fundamental principles is that testing is integrated throughout the
life cycle. Testing is considered to be an integral activity within DSDM, must begin
as early in the project as possible, and must continue throughout the project life
cycle. Testing is a mandatory part of each increment and is conducted to ensure that
the software meets its business needs and is robust and reliable.1
“Fitness for business purpose” is another important DSDM fundamental principle
and informs one of the key acceptance criteria for the software: delivering a system
that addresses the current business needs. In practice, this means that it is better to
deliver software that supports critical business functionality than to deliver a more
complete, more polished, or more perfect system.
Co-location of users and developers ensures that users are able to continuously
evaluate the quality of the software being developed and to provide the developers

1 It is interesting to note that this principle is listed at number eight out of the nine fundamental DSDM

Appendix C. The Principles of the Dynamic Systems Development Method

with essential feedback on the suitability of the software. A speci¬c DSDM example of
this approach allows for the delivery of “partial solutions” to support urgent business
needs, with later versions of the software implemented using the feedback gained
from the users.
Another key testing requirement that is enshrined as one of DSDM™s fundamental
principles is the ability to be able to revert quickly, easily, and accurately to previous
versions of the application under test. In practice, this requirement is typically
supported through the use of a con¬guration and change management tool (see
[88], for example).
While DSDM has been created to be agile enough to expect and to deal with
frequently changing requirements, it also incorporates the need to formally man-
age those requirements changes, ensuring that the changes are promulgated to all
members of the project team that need to know, such as the testers.
In terms of the testing artifacts (i.e., test documents and items created or used
during the project), the following are commonly employed in DSDM projects:

Test plan “ Testing effort is initially considered during the DSDM preproject
phase (see later) and re¬ned during the later phases and stages.
Test record “ A Test Record is created or updated during each iteration of the
DSDM project life-cycle phase and is used as part of the process of documenting
the implementation strategy for that iteration. The test record incorporates test
scripts, test procedures, and test results:
A test procedure provides the means of documenting the speci¬cation for a
A test script documents the detailed implementation of a test procedure,
describing navigation and veri¬cations, and is used by the tester to execute
one or more tests.
The test results provide a documented record of the results of executing the
test scripts.

Although the quality of the delivered system is considered the responsibility of
all members of the team, DSDM identi¬es a number of roles with speci¬c quality
assurance responsibilities:

Technical coordinator “ The Technical Coordinator has overall responsibility for
designing the system architecture as well as responsibility for controlling the
technical quality of the project.
Tester “ The Tester role is responsible for implementing the test plans, writing
the test procedures, implementing and executing the test scripts, recording the
test results, and reporting on the test results.
Project manager and team leader “ These management roles have responsibility
for the planning and day-to-day implementation of quality within the project,
Appendix C. The Principles of the Dynamic Systems Development Method

C.3 Fundamental Principles and Assumptions of DSDM
An important foundation of DSDM is the recognition that there is no one-size-¬ts-all
solution to developing software and that no development framework can provide all
the answers. DSDM addressed this observation by closely following nine fundamental
principles and eight additional assumptions, which, if adhered to, provide a higher
likelihood of project success.
The nine fundamental principles are as follows:

1. Active user involvement is imperative “ Co-location and close collaboration
between users and developers are vital in running an ef¬cient and effective project,
allowing decisions to be made jointly and without ambiguity.
2. DSDM teams must be empowered to make decisions “ DSDM project teams con-
sist of developers, testers, and users who must be empowered to make decisions
that are important to the progress of the project, without waiting for higher-level
approval. Testers and developers must be able to rapidly decide on technical solu-
tions, whereas the business users must be able to decide on key requirements for
the application.
3. The focus is on frequent delivery of products “ DSDM projects emphasize fre-
quent delivery of products, with the assumption that to deliver something “good
enough” earlier is always better than to deliver something that is “perfect” later.
By delivering product frequently from an early stage of the project, the product
can be tested and reviewed and the test record and review document can be taken
into account at the next iteration or phase.
4. Fitness for business purpose is the essential criterion for acceptance of deliver-
ables “ The main criterion for acceptance of a “deliverable” is delivering a sys-
tem that addresses the current business needs. Delivering a perfect system that
addresses all possible business needs is less important than focusing on critical
5. Iterative and incremental development is necessary to converge on an accurate
business solution “ In DSDM emphasis is put on evolving a system via incremental
steps. Within this process, partial solutions may be delivered to ful¬ll immediate
business need, with later versions of a system built upon the lessons learned from
users in the feedback process. Only by explicitly reworking a system in this way
can an accurate business solution be produced.
6. All changes during development are reversible “ It must be possible to quickly,
easily, and accurately revert to a previous version of the system under develop-
7. Requirements are baselined at a high level “ The high-level requirements for the
system should be agreed and in a static state before the project starts. This does
not preclude the likelihood that detailed requirements will change as the project
8. Testing is integrated throughout the life cycle “ Testing is not considered to be
a separate phase or activity within DSDM and is expected to begin as early in the
Appendix C. The Principles of the Dynamic Systems Development Method

project as possible and to continue throughout the project life cycle. Testing is
an integral part of each increment and is conducted to ensure that the software
meets its business needs and is robust and reliable.
9. A collaborative and cooperative approach between all stakeholders is essential “
Because the low-level requirements are not ¬xed at the outset in a DSDM project,
there must be continuous cooperation and collaboration between sponsors, devel-
opers, and users throughout the life of a project.

The additional eight assumptions are as follows:

1. No system is built perfectly on the ¬rst try “ As a rule of thumb, 80% of the
business bene¬t comes from 20% of the design requirements; therefore, DSDM
starts implementing this ¬rst 20%, which is suf¬cient as long as the end users
are satis¬ed with the functionality, and that the missing 80% does not cause any
serious business consequences. This mitigates the risk of the project going over
deadline and over budget.
2. Project delivery should be on time, on budget, and of good quality “ DSDM
emphasizes the need to meet project timescales and cost, but not at the expense
of quality.
3. Each step of the development only need be completed far enough for the next
step to begin “ This practice allows a new iteration of the project to commence
without unnecessary delay. Changes in design can coincide with the changes in
demand from the end users, because every iteration of the system is improved
4. Both project management and development techniques are incorporated “
DSDM recognizes that technical agile best practices cannot exist successfully
in a project management vacuum and acknowledges the need to follow good
project management techniques.
5. DSDM can be applied in new projects and for expanding current systems “ Just
because the previous phase of a particular development project was based on
another development approach, the adoption of DSDM for future development
and enhancements to the system is not precluded.
6. Risk assessment should focus on business function being delivered, not on the
development process nor its artifacts “ Projects can go wrong in spite of following
good development practices or having produced very elegant but time-consuming
design or requirement documents; DSDM emphasizes the scrutiny of delivered
business function as the means of assessing project risk.
7. Management rewards product delivery rather than task completion “ DSDM
considers customer satisfaction and success using the delivered business func-
tionality to be a better measure of project progress than developers reporting the
completion of a particular iteration.
8. Estimation should be based on business functionality instead of lines of code “
As with assumptions 6 and 7, this assumption focuses again on the delivery of
successful business functionality to the customer rather on traditional metrics
of counting the lines of code or function points.
Appendix C. The Principles of the Dynamic Systems Development Method

Project Life-cycle Phase

Business Study

Preproject Postproject
Phase Phase
Functional Model

Design & Build

C.1 Graphical overview of the DSDM phases and stages.

C.4 The DSDM Phases and Stages
DSDM consists of three phases and a number of substages (Figure C.1 provides a
graphical overview of the DSDM phases and stages):

The preproject phase sets the context of the project and ensures it is set up
correctly from the outset to give the project the best likelihood of success. Key
products delivered from this phase include the initial de¬nition of the business
problem to be addressed, budget and resourcing, outline scope and plans for the
feasibility study, and a decision on whether or not to proceed with the project.
The project life-cycle phase combines both sequential and iterative stages, leading
to the incremental development of the system. Following initial feasibility and
business study stages, the project iterates through the functional model, design
and build, and implementation stages:
Feasibility study “ In this stage, the likelihood of the project meeting the
customer™s business requirements is evaluated. Other issues that are covered
in this stage include assessing the suitability of DSDM in implementing the
customer™s business requirements, reviewing possible technical solutions to
the business problem, and producing initial estimates of costs and timescales.
The key products from this stage include
a feasibility report,
an optional feasibility prototype,
an outline plan that also addresses quality issues, and
a risk log.
Appendix C. The Principles of the Dynamic Systems Development Method

Business study “ In this stage, the business processes to be supported are
scoped out. Other issues that are covered in this stage include outlining the
future development in terms of prototyping deliverables; identifying customer
representatives to be involved in the prototyping activities; prioritizing the
requirements of the proposed system; reviewing the project risks and updating
the risk log; establishing the foundation for technical development and test
to proceed; and scoping the nonfunctional requirements, including usability,
security, performance, and maintainability requirements. The key products
from this stage include
business area de¬nition,
prioritized requirements list,
development plan,
system architecture de¬nition, and
updated risk log.
Functional model iteration “ In this stage, static models (such as visual class
and data models) and working software prototypes are used to animate and
explore the required business functionality with the customer. Through early
exposure to the software, the customer is able to provide essential feedback
to the developers. This stage is also used to discuss, re¬ne, and document
those nonfunctional requirements that the prototypes may not be able to
demonstrate. The key products from this stage include
a functional model plus review records,
a list of nonfunctional requirements,
any functional prototypes developed during the stage,
an implementation plan including time-box plans, and
an updated risk log.
Design and build iteration “ In this stage, the system is developed against
the functional model and incorporates any reusable aspects of the proto-
types. Nonfunctional requirements are also addressed. Testing is conducted
to ensure the software satis¬es the customer business requirements. The key
products from this stage include
time-box plans,
design prototypes plus review records, and
tested software plus test records.
Implementation “ In this stage, the tested system is installed in the customers™
working environment. As part of this process, the users, operators, and support
staff are trained on their speci¬c aspects of the system. This stage is also used
to elicit any additional development requirements for future iterations. The
key products from this stage include
the tested and delivered system;
the trained users, operators, and support staff;
user documentation; and
an increment review document.
Appendix C. The Principles of the Dynamic Systems Development Method

Following the implementation stage, the development process either con-
tinues with a further functional model iteration or, if development is complete,
the project enters the postproject phase.
The postproject phase covers postdeliver activities, such as maintenance, en-
hancements, and ¬xes, and is used to ensure the ongoing effective and ef¬cient
operation of the delivered system.

C.5 DSDM Roles and Responsibilities
Compared with the relatively few roles found in Extreme Programming, DSDM
de¬nes a larger number of project roles, each with well-de¬ned responsibilities:

Executive sponsor “ the executive sponsor is a senior member of staff in the user
organization who has the power and in¬‚uence to commit appropriate user funds
and resources as required by the project. This role is also termed the “project
Visionary “ the visionary role is taken by a user who has the most accurate
perception of the business objectives of the system and the project and who has the
responsibility to initialize the project by ensuring that essential requirements are
found early on. Another visionary task is to supervise and keep the development
process on the right track.
Ambassador user “ The ambassador user is able to communicate with the user
community at all levels (from management through to user level) and is able to
bring the knowledge of the user community into the project. The ambassador
user is able to mobilize the users to ensure that the developers receive enough
user feedback during the development process.
Advisor user “ The advisor user is any user that is able to provide the developers
with appropriate depth of knowledge and/or experience about some element of
the project, such as a particular aspect of the business needs that are being
Project manager “ The project manager provides overall management of the
project, including responsibility for planning, resourcing, progress monitoring,
reporting to senior stakeholders, tasking the team leader, and so on. Although
the project manager is typically drawn from the IT staff, it is also possible for the
project manager to be drawn from the user community.
Technical coordinator “ the technical coordinator is responsible for design-
ing the system architecture and controlling the technical quality of the pro-
Team leader “ the team leader provides day-to-day leadership of the project team,
implements the project manager™s vision for the running of the project, and works
to ensure that the project environment is free of any issues that might impact on
the effectiveness and ef¬ciency of the team.
Developer “ the developer is responsible for interpreting the system require-
ments, generating the design (through visual modeling, for example), writing
the deliverable code, and building the prototypes.
Appendix C. The Principles of the Dynamic Systems Development Method

Tester “ the tester is responsible for implementing the test plans; writing the
test cases, procedures, and scripts; executing the tests; and recording the results.
The tester is also responsible for updating the test record and reporting on the
progress and results of testing.
Scribe “ the scribe is responsible for documenting the requirements, agreements,
and decisions made during a DSDM workshop (see next section).
Facilitator “ the facilitator is responsible for organizing and facilitating the DSDM
workshops (see next section).
Specialist roles “ A number of specialist roles may be employed within the project
as and when needed and dependent on the size and scope of the project. These
could include automation engineers, business architects, quality managers, and
system integrators, for example.

C.6 DSDM Techniques
DSDM incorporates a number of speci¬c techniques:

Testing “ As described in the preceding sections, testing is considered an essential
and integral aspect of DSDM projects. Through the iterative nature of DSDM
projects, testing is mandated to begin as early in the project as possible and to
continue throughout the project at each iteration. Testing covers both functional
and nonfunctional aspects of the system.
The MoSCoW Principle “ MoSCoW (must, should, could and, would) provides a
means of prioritizing requirements within a DSDM project, by allowing require-
ments to be identi¬ed that
must be implemented for the software to meet the business needs;
should be implemented if at all possible, but without which the project can
still be successful;
could be implemented as long as the time and effort involved do not impact
the ¬tness of the business needs of the project; and
would be implemented if spare time and budget are left at the end of an
Time boxing [17] “ It is a technique used to manage the time and cost aspects
of tasks within a DSDM project. Using this approach, at each iteration a num-
ber of business requirements are selected for implementation according to the
MoSCoW principle. As the iteration proceeds, should time and budget allow,
further requirements are selected and implemented.
Prototyping “ The production of animated models and working prototype soft-
ware is a key technique that DSDM employs in the process of developing the ¬nal
system. This approach allows the developers to explore the business requirements
with the users, to show them working examples of business functionality, and
to obtain immediate feedback that isused to re¬ne the ¬nal delivered software.
Conversely, prototyping can be used to manage the users™ expectations of the
developed software, ensuring that the delivered system closely matches the user
perceptions of how the software should appear and how it should perform.
Appendix C. The Principles of the Dynamic Systems Development Method

Workshops “ A DSDM workshop is a structured meeting attended by user and
developer representatives that is convened to gain understanding of a particular
project issue (such as business needs, requirements, and/or business function-
ality). A facilitator manages the agenda and progress of the meeting, while a
scribe is responsible for documenting the information gained as a result of the
Visual modeling “ The failure of users to successfully communicate business
requirements and other domain knowledge to the developers has historically
been a major cause of project failure; quite simply, the ¬nal delivered system fails
to match the user expectations in terms of what they thought they had agreed
with the development team. Visual modeling is a powerful technique that helps
bridge the knowledge gap between users who are expert in the business aspects
of the system and the developers. Techniques such as use cases [8] and notations
such as the Uni¬ed Modeling Language (UML [33]) allow diagrams to be created
that allow users and developers to con¬rm their understanding of what needs to
be developed in a simple and unambiguous manner.
Con¬guration management “ Because of the highly dynamic nature of DSDM
projects, with changing requirements and rapid development of code, good con-
¬guration and change management are essential to the success of a project.
Within DSDM projects, the requirement for good con¬guration and change man-
agement is typically supported by means of tools ([88], for example), of which
there are many available to choose from.

The Practices of Scrum
A pig and a chicken are walking down a road. The chicken looks at the pig and
says, “Hey, why don™t we open a restaurant?” The pig looks back at the chicken
and says, “Good idea, what do you want to call it?” The chicken thinks about it
and says, “Why don™t we call it ˜Ham and Eggs™?” “I don™t think so,” says the
pig, “I™d be committed but you™d only be involved!”

D.1 Introduction
This appendix reviews the essential rules and practices of Scrum,1 focusing in more
detail on the testing aspects of the method.
The Scrum rules and practices are discussed under the following sections:
Scrum General Practices,
Scrum Roles and Responsibilities,
The Sprint,
Scrum Meetings, and
Scrum Artifacts.

D.2 Scrum General Practices
Customers must become a part of the development team; it is essential that the
customer is genuinely interested in the success of the project.
There should be frequent intermediate deliveries with working functionality; this
enables the customer to get exposure to working software earlier and enables the
project to change its requirements according to changing needs.
The development team should be alert to project risks and develop appropriate
mitigation strategies; valid risk mitigation, monitoring, and management should
be actively performed throughout the project.
Problems, issues, and risks must not be swept under the carpet; no one should
be penalized for identifying or highlighting any unforeseen problem.
There should be transparency in planning and module development; everyone
must be aware of who is accountable for what and by when.

1 Scrum versus SCRUM: although Scrum is often shown in the uppercase form “ SCRUM “ it was not
originally employed as an acronym, which is why my preference throughout this book is for Scrum.
Sincere apologies to anyone who prefers SCRUM, and who is seriously offended by this choice.

Appendix D. The Practices of Scrum

Frequent stakeholder meetings should be held to monitor progress, with dash-
board/stakeholders™ updates; procedures must be put in place to ensure visibility
of potential slippage or deviation in a timely manner to allow it to be corrected.
The project environment and work time must be energized; “working more
hours” does not necessarily mean “producing more output.”

D.3 Scrum Roles and Responsibilities
The roles that are de¬ned in Scrum are divided into two high-level groups: pigs and
chickens, based on the joke presented at the beginning of this appendix.
The implication is that the pigs represent those roles that are committed to build-
ing software regularly and frequently, while all other roles in the project are consid-
ered to be chickens, who, although interested in the project, are effectively irrelevant
because if the project fails they weren™t the ones that committed to doing it. The
needs, desires, ideas, and in¬‚uences of the chicken roles are taken into account but
should not be allowed to affect, distort, or get in the way of the actual Scrum project.

The “Pig” Roles
Pigs are the ones committed to the project and the Scrum process; they are the ones
with “their bacon on the line!” The pig roles include
The product owner “ The product owner represents the voice of the customer
and ensures that the Scrum team is focused on the right issues from a business
perspective. The product owner writes user stories, prioritizes them, then places
them in the product backlog.
The ScrumMaster (or Facilitator) “ Scrum is facilitated by a ScrumMaster, whose
primary job is to remove impediments to the ability of the team to deliver the
sprint goal. The ScrumMaster is not the leader of the team (as they are self-
organizing) but acts as a buffer between the team and any distracting in¬‚uences.
The ScrumMaster ensures that the Scrum process is used as intended. The
ScrumMaster is the enforcer of rules and sprints of practice.
The Scrum team “ A small team of ¬ve to nine people with cross-functional skills
to do the actual work (tester, developer, designer, etc.).

The “Chicken” Roles
Chicken roles are not part of the actual Scrum process but must be taken into
account. An important aspect of this agile approach is the practice of involving
users, business people, and other stakeholders into the process; it is important for
these people to be engaged and provide feedback against the outputs for review and
planning of each sprint. The chicken roles include the following:
The users “ The software is being built for someone! There is a Scrum mantra
that says, “Never forget that software that is not used is like a tree falling in the
forest “ was it ever written?”
Appendix D. The Practices of Scrum

Stakeholders “ The people who enable the project but are not directly involved
in the process. This includes executives.
Consulting experts “ The people who provide expertise that is not required on
every sprint. It is possible for a chicken to become a pig as part of the Scrum
team during some sprints.

D.4 The Sprint
Scrum follows an incremental development approach, whose increments are termed
sprints. During each sprint, a 15“30-day period (length decided by the team), the
team creates an increment of shippable software, or deliverable.
The set of features that go into each sprint come from the product backlog, which
is a prioritized set of high-level requirements of work to be done. The choice of which
backlog items go into the sprint is determined during the sprint planning meeting.
During this meeting the product owner identi¬es the items in the product backlog
that she or he wants completed. The team then determines how much of this they
can commit to complete during the next sprint.
During the sprint, the team works to complete the ¬xed set of items (termed
backlog items). During the sprint no one is able to change the backlog, which means
that the requirements are frozen for a particular sprint.

D.5 Scrum Meetings
In line with its goals of promoting good communications, proactively highlighting
project risks and issues, transparency in planning and development, and stakeholder
involvement, meetings are a key aspect of a successful Scrum project. The different
types of Scrum meetings include the following:

The sprint planning meeting. Prior to each sprint, a sprint planning meeting is
convened and attended by the product owner, ScrumMaster, the entire Scrum
team, and any interested and appropriate management or customer representa-
tives. The purpose of the meeting is threefold:
The product owner outlines the highest priority features that need to be devel-
oped and tested to the Scrum team members, who ask suf¬cient questions to
allow them to determine which tasks they will move from the product backlog
into the sprint backlog.
The Scrum team members discuss and agree how they will convert the selected
sprint backlog into an increment of potentially shippable product function-
ality. The output from this activity is a list of tasks, task estimates, and
assignments that will start the team on the work of developing the function-
Together, the Scrum team and the product owner agree on a sprint goal
that succinctly describes what the sprint will achieve, and which will be used
during a sprint review meeting to assess the success of the sprint.
Appendix D. The Practices of Scrum

The Scrum. Each day during a sprint, a project status meeting is arranged. This
is called a Scrum. The Scrum has speci¬c guidelines:
The meeting starts precisely on time with team-decided punishments for
tardiness (e.g., money, push-ups, hanging a rubber chicken around your
All are welcome, but only “pigs” may speak.
The meeting is time-boxed at ¬fteen minutes irrespective of the size of the
Where practically possible, all attendees should stand.
The meeting should happen at the same location and same time every day.
During the meeting, each team member answers three questions:
1. What have you done since yesterday?
2. What are you planning to do by tomorrow?
3. Do you have any issues or impediments preventing you from accomplish-
ing your goal? (It is the role of the ScrumMaster to remember these
On a larger Scrum project, which potentially has a number of distinct teams,
it may become impractical for all the stakeholders to get together for a single
meeting. Under these circumstances, a Scrum of Scrums may be employed. This
is a meeting attended by one or more representatives from each of the team
Scrums, and can be used as an opportunity to obtain information on areas of
integration and overlap between the teams.
Sprint retrospectives. After each sprint a brief sprint retrospective is held, at which
all team members re¬‚ect about the past sprint. The purpose of the retrospective
is to make continuous process improvement. This meeting is time-boxed at four

D.6 Scrum Artifacts
The following artifacts (things that are created, used, and/or delivered) are employed
during a Scrum project:

User stories “ Originally borrowed from Extreme Programming (see Appendix
B), user stories provide the means of capturing user requirements throughout
the project. Written in simple, nontechnical, jargon-free language, a user story
is a simple statement of what a user wants some feature of the system to do. They
should focus on documenting the who, the what, and the why of the requirement
rather than specifying the “how” aspects of the required feature; a very basic
template for a user story could be written as, “As a User Role , I want to Goal ,
so that I can Reason .”
Product backlog “ The product backlog is a high-level document for the entire
project. It contains broad descriptions of all required features, wish-list items,
and so on. It is the “what” that will be built. It is open and editable by anyone. It
Appendix D. The Practices of Scrum

contains rough estimates, usually in days. This estimate helps the product owner
to gauge the timeline and, to a limited extent, priority (e.g., if “add search” feature
is estimated at three days rather than three months, that may affect the product
owner™s decision on what to do next).
Sprint backlog “ The sprint backlog is a detailed document containing infor-
mation about how the team is going to implement the requirements for the
upcoming sprint. Tasks are broken down into hours with no task being more
than sixteen hours. If a task is greater than sixteen hours, it should be broken
down further. Tasks on the sprint backlog are never assigned; rather tasks are
signed up for by the team members as they like.
Burndown “ The burndown chart is a publicly displayed chart showing the effort
remaining over time. A burndown chart presents a graph of effort versus time and
is updated daily (and/or as required). Typically, there are two types of burndown
a sprint burndown chart, recording the daily progress of a sprint, and
a product burndown chart, showing overall monthly progress.
Dashboard “ It is possible to drown in too much project information; information
overload prevents team members from being able to focus on key metrics and
indicators. A dashboard is a tool intended to provide all members of the team
with a concise view of key project metrics, such as tasks, impediments, and bugs.
Typically, an automated tool is used to implement the dashboard, either developed
in-house, obtained from a number of shareware sources, or purchased from one
of the suppliers producing such tools.
Increment of shippable software “ The deliverable from a sprint is a software
product termed an increment of shippable software. Once this software deliverable
is transitioned into routine use by the customer, it becomes a release.

Agile Test Script Template

E.1 Introduction
The following pages of this appendix contain a test script template (Figure E.1) that
may be copied and used within your own testing task or project.1
The test script template contains the following sections:
Project ID “ the unique project identi¬er;
AUT Name “ the de¬nitive name of the Application Under Test (front sheet only);
AUT Version “ the de¬nitive version information for the Application Under Test
(front sheet only);
Iteration ID “ the unique identi¬er for the iteration this test is being conducted
in (front sheet only);
Date of Test “ the planned start date of testing (front sheet only);
Test ID “ the unique identi¬er for the test;
Purpose of Test “ a brief description of the purpose of the test including a
reference, where appropriate, to the requirement that is to be tested (consider
providing references to the requirements speci¬cation, design speci¬cation, user
guide, operations guide, and/or installation guide), as well as any dependencies
from or to other test scripts/test cases;
Test Environment “ a brief description of the environment under which the test
is to be conducted (may include a description of the state of the AUT at the start
of this test, details regarding the platform or operating system, as well as speci¬c
information about data used in this test);
Test Steps “ concise, accurate, and unambiguous instructions describing the pre-
cise steps the tester must take to execute the test, including navigation through
the AUT as well as any inputs and outputs; and
Expected Result “ a brief and unambiguous description of the expected result of
executing the test.
1 Where the test script template provided in this appendix does not exactly match your needs, an electronic
version of the template can be obtained at the following URL for you to customize: http://www.cambridge
.org/9780521191814 Cambridge University Press Web Site / Agile Script Template

Appendix E. Agile Test Script Template

Text appearing in angle brackets ( ) denotes a place marker, which must be replaced
with the appropriate information for a particular testing phase. For example, Client
should be replaced by the name of your own company or organization.
Figure E.2 provides an example of how the test script template provided in this
appendix might be completed in practice.
Appendix E. Agile Test Script Template

(front sheet)
Project ID
AUT Name
Iteration ID Date of Test

Test ID
Purpose of Test


E.1 Test script template.
Appendix E. Agile Test Script Template

Test Steps

Expected Result

Page 1 of Pages

E.1 (continued)
Appendix E. Agile Test Script Template

(continuation sheet)
Client Test Script
Project ID

Test ID
Purpose of Test


E.1 (continued)
Appendix E. Agile Test Script Template

Test Steps

Expected Result

Page of Pages

E.1 (continued)
Appendix E. Agile Test Script Template

(front sheet)
Project ID CTS Group News Wiki and Process Framework
C T S Wiki v1 .0
AUT Title
Iteration Date of Test 07/07/2008

Test ID 02-Team-Org-Chart-01
To ensure that:
Purpose of Test

… It is possible to navigate to the screen showing the Team Org Chart
… It is possible to view the whole Team Org Chart, and that it is legible

Test The test environment is as follows:

… Client Hardware: IBM T60 Laptop
… Server: Company Intranet system
… No other applications should be running on the laptop
… The Wiki should visible and at the top level intro page, with the
be running
login dialog box

… Hand-rafted “login data” is held in C:\test-dir\login.dat

E.2 Specimen completed test script for the CTS Company Wiki project.
Appendix E. Agile Test Script Template

In the login dialog box, the tester should:
Test Steps

… Left-click into the “User Name” field and enter “testuser”
… Left-click into the “Password” field and enter “password”
… Left-click on the “OK” button
… Once the nextnavigation pane left click on the CTS Org Chart link in
screen appears,
the left hand

On completing the above steps, the CTS Team Org Chart should be
Expected Result

… Verify that the whole org chart is visible on the screen
… Verify that the contents of the org chart is legible

Page 1 of 1 Page

E.2 (continued)

Agile Test Result Record Form Template

F.1 Introduction
The following pages of this appendix contain a test result record form template
(Figure F.1) that may be copied and used within your own testing task or project.1
The test result record form template contains the following sections:
Project ID “ the unique project identi¬er;
AUT Title “ the de¬nitive title of the Application Under Test (front sheet only);
AUT Version “ the de¬nitive version information for the AUT (front sheet only);
Iteration ID “ the unique identi¬er for the iteration this test is being conducted
in (front sheet only);
Date of Test “ the date on which the test was performed (front sheet only);
Test ID “ the unique identi¬er for the test;
Time of Test “ the time at which each individual test case was started;
Observed Test Result “ a brief textual description of the result of the test;
Test Result Category “ the test result category assigned to this test (as speci¬ed
from the Test Speci¬cation document for this testing phase; see Appendix D);
Test Error Description “ a brief textual description (if appropriate) of the observed
test error;
Name of the Tester;
Tester Signature “ the signature of the tester, recording their participation in
the test, their observation of the result of the test, and their agreement to the
documented test result;
Name of the Test Observer “ this might be the user/customer representative, or
somebody from the quality assurance group (if your organization has one); and
Test Observer Signature “ the signature of the test observer, recording their
observation of the result of the test, and their agreement to the documented test
1 Where the test result record template provided in this appendix does not exactly match your needs, an
electronic version of the template can be obtained at the following URL for you to customize: http://www.
cambridge.org/9780521191814 Cambridge University Press Web Site / Agile Script Template .

Appendix F. Agile Test Result Record Form Template

With the exception of the last item, these sections of the test result record form
are completed by the tester in consultation with the independent test observer and
any other staff attending the testing phase in an of¬cial capacity (such as the user
representative in User Acceptance Testing).
Text appearing in angle brackets ( ) denotes a place marker, which must be
replaced with the appropriate information for a particular testing phase. For example,
Client should be replaced by the name of your own company or organization.
Figure F.2 provides an example of how the test result record form template
provided in this appendix might be completed in practice.
Appendix F. Agile Test Result Record Form Template

(front sheet)
Project ID
AUT Version
AUT Title
Iteration ID Date of Test

Test ID Time of Test
Observed Test

F.1 Test result record form template.
Appendix F. Agile Test Result Record Form Template

Test Result
Test Error

Tester Name Tester Signature
Observer Signature
Test Observer
Page 1 of Pages

F.1 (continued)
Appendix F. Agile Test Result Record Form Template

(continuation sheet)
Project ID

Test ID Time of Test
Observed Test

Test Result

F.1 (continued)
Appendix F. Agile Test Result Record Form Template

Test Error

Tester Name Tester Signature
Observer Signature
Test Observer
Page of Pages

F.1 (continued)
Appendix F. Agile Test Result Record Form Template

CTS Wiki Test Reset Record Form (front sheet)
Project ID CTS Group News Wiki and Process Framework
AUT Version
C T S Wiki v1 .0
AUT Title
Iteration ID Date of Test 07/07/2008

Time of Test
Test ID
Having “
Observed Test

… Left-clicked into the “User Name” field and entered “testuser”
… Left-clicked into the “Password” field and entered “password”
… Left-clicked on the “OK” button
… And havingpane of the windowCTS Org Chart link thethe left hand
left-clicked on the in
navigation that was displayed, CTS Team
Org Chart was to be displayed.

I was able to verify that:

… The whole org chart is visible on the screen.
… The complete content of the org chart was legible.

F.2 Specimen completed test result record form for the CTS Company Wiki project.
Appendix F. Agile Test Result Record Form Template

Test Result Pass
Test Error

Tester Name D Chana
Tester Signature
Dass Chana
Observer Signature
Test Observer A N Other
Andy Nigel Other
Page 1 of 1 Page

F.2 (continued)

Agile Test Summary Report Template

G.1 Introduction
The following pages of this appendix contain a test summary report template, which
may be copied and used as the basis of a test summary report for a particular iteration
or phase of the test project.1
Text appearing within the body of this template in angle brackets ( ) denotes
a place marker, which must be replaced with the appropriate information for a
particular testing phase.
Text that appears in italic is provided for information only (such as illustrative
examples) and should not appear in the ¬nal test summary report.

1 Where the test summary report template provided in this appendix does not exactly match your
needs, an electronic version of the template can be obtained at the following URL for you to cus-
tomize: http://www.cambridge.org/9780521191814 Cambridge University Press Web Site / Agile Script
Template .

Appendix G. Agile Test Summary Report Template

Test Summary Report
Document Information {to Client Doc Standard}
Project ID: Project ID the unique ID for this testing project

Document Ref: Doc Ref a unique document reference for this document
Iteration ID: Iteration ID the unique iteration ID


. 9
( 10)