Download to read offline
![2 Agile Testing: How to Succeed in an Extreme Testing Environment
additional costs caused by problems associated with impact of postimplementation
faults [1].
The most common reason that companies put up with this situation is that they
take a short-term view of the projects they run; it is much better to just get on with
it and “make progress” than to take a more enlightened, but longer-term, view to
actually address and fix the problems.
Many organizations are now adopting some form of formal test process as the
solution to these problems. In this context, a process provides a means of document-
ing and delivering industry best practice in software development and testing to all
of the staff in the organization. The process defines who should do what and when,
with standard roles and responsibilities for project staff, and guidance on the correct
way of completing their tasks. The process also provides standard reusable templates
for things like test plans, test scripts, and testing summary reports and may even
address issues of process improvement [2].
Although there have been numerous attempts to produce an “industry standard”
software testing process (e.g., the Software Process Engineering Metamodel [3]),
many practitioners and organizations express concerns about the complexity of such
processes. Typical objections include:
왘 “The process is too big” – there is just too much information involved and it takes
too long to rollout, adopt, and maintain.
왘 “That’s not the way we do things here” – every organization is different and there
is no one-size-fits-all process.
왘 “The process is too prescriptive” – a formal process stifles the creativity and
intuition of bright and imaginative developers and testers.
왘 “The process is too expensive” – if we are trying to reduce the cost of soft-
ware development, why would we spend lots of money on somebody else’s best
practices?
Interestingly, even where individuals and organizations say they have no process,
this is unlikely to be true – testers may invent it on the fly each morning when they
start work, but each tester will follow some consistent approach to how he or she
performs their testing. It is possible for this “approach” to be successful if you are
one of those talented supertesters or you work in an organization that only hires
“miracle QA” staff. For the rest of us, we need to rely on documented best practices
to provide guidance on the who, the what, and the when of testing, and to provide
reusable templates for the things we create, use, or deliver as part of our testing
activities.
So, here is the challenge: how is it possible to produce good-quality software, on
time and to budget, without forcing a large, unwieldy, and complex process on the
developers and testers, but still providing them with sufficient guidance and best
practices to enable them to be effective and efficient at their jobs? To restate this
question, what is the minimum subset of industry best practice that can be used
while still delivering quality software?](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-22-2048.jpg)
![2 Old-School Development and Testing
Testing is never completed, it’s simply abandoned!
Simon Mills
2.1 Introduction
This chapter discusses what software development and testing process is, reviews
the historical development of process, and concludes by providing a review of the
elements of a traditional or “classic” software testing process, providing a useful
baseline for the rest of the book to build on.
2.2 So, What Is Process?
A process seeks to identify and reuse common elements of some particular approach
to achieving a task, and to apply those common elements to other, related tasks.
Without these common reusable elements, a process will struggle to provide an
effective and efficient means of achieving those tasks, and find it difficult to achieve
acceptance and use by other practitioners working in that field.
Test process is no different; we have many different tasks that need to be achieved
to deliver effective and efficient testing, and at a variety of different levels of testing
from component/unit/developer testing, through integration/module testing, on into
systems testing, and through to acceptance testing [4].
Even before testing process was “invented”, good testers have done things in a
particular way to achieve good results – such as the best way to find the most defects,
to complete testing more quickly or more cheaply, to save time by reusing things
they had produced in earlier testing projects (such as a template for a test plan or a
test script), or to ensure consistent nomenclature (such as common terms for testing
phases).
Such enlightened practitioners were even known to share such best practices
with their colleagues, passing on or swapping reusable templates, publishing papers
on testing techniques, or mentoring other staff on test management approaches, for
example.
As the IT industry matured, with customers demanding increasingly complex
systems, of ever higher quality, in shorter timescales and with lower cost, the
7](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-27-2048.jpg)
![8 Agile Testing: How to Succeed in an Extreme Testing Environment
Requirements
Design
Implementation
Testing
Maintenance
Risk Profile
2.1 The Waterfall Phases and Risk Profile (dotted line).
resulting commercial pressures forced those organizations developing software to
seek methods to ensure their software development was as effective and efficient as
possible. If they did not find the means to deliver software faster, cheaper, and with
better quality, their competitors would.
Successive waves of new technologies, such as procedural programming, fourth-
generation languages, and object orientation, all promised to ensure reductions in
the occurrence of defects, to accelerate development times, and to reduce the cost
of development. Interestingly, it was observed that it was still possible to write poor-
quality software that failed to achieve its purpose and performed poorly or included
defects, no matter what technologies were used!
As with so many instances of a new technology failing to solve a particular
problem, the issue actually turns out to be a people problem. Human beings need
guidance, they need to build upon the knowledge and experiences of others, they need
to understand what works and what doesn’t work, and they need to avoid wasting time
reinventing things that other practitioners have already successfully produced and
used. Project chaos, where each project and practitioner uses different techniques,
employs different terminology, or uses (or worse, reinvents from scratch) different
documentation, was increasingly considered to be unacceptable.
The following sections review a number of the early approaches to software
development and testing that sought to avoid such project chaos.
2.3 Waterfall
One of the earliest approaches to software development is the waterfall approach.
A paper published by Winston W. Royce in the 1970s [5] described a sequential
software development model containing a number of phases, each of which must be
completed before the next begins. Figure 2.1 shows the classic interpretation of the
phases in a waterfall project.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-28-2048.jpg)
![9 Old-School Development and Testing
From a quality perspective, the waterfall approach has been often criticized
because testing begins late in the project; as a consequence, a high degree of project
risk (that is, failure of the software to meet customer expectations, to be delivered
with acceptable levels of defects, or to perform adequately) is retained until late into
the project. With the resultant reworking and retesting caused by the late detection
of defects, waterfall projects were also likely to incur additional effort, miss their
delivery dates, and exceed their budgets.
The waterfall approach has also been criticized for its lack of responsiveness to
customer requests for changes to the system being developed. Historically, it was
typical for all of the requirements to be captured at the start of the project and to
be set in stone throughout the rest of the development. A frequent result of this
approach was that by the time the software had been delivered (sometimes months
or even years later), it no longer matched the needs of the customer, which had
almost certainly changed by then.
Because of increasing dissatisfaction with the rigid structure of waterfall projects,
other solutions were investigated that would be more flexible in terms of addressing
changing requirements.
2.4 Spiral
Many attempts were made to address the shortcomings of the waterfall approach,
such as the spiral model of software development defined by Barry Boehm in 1988 [6].
Intended for use in large, complex, and costly projects, and intended to address the
issues of meeting customer requirements, this incremental development process
relied heavily on the development and testing of a series of software prototypes of the
final system. The typical steps involved in a spiral model–driven project are as follows:
1. In discussion with the customer, the requirements for the system are defined and
documented in as much detail as possible.
2. An initial design is created based on the requirements.
3. A sequence of increasingly complete prototypes are constructed from the design
in order to
컄 test the strengths and weaknesses of the prototypes, and to highlight any
risks;
컄 assist in refining the requirements by obtaining customer feedback; and
컄 assist in refining the planning and design.
4. The risks identified by testing the prototypes are reviewed with the customer,
who can make a decision whether to halt or continue the project.
5. Steps 2 through 4 are repeated until the customer is satisfied that the refined
prototype reflects the functionality of the desired system, and the final system is
then developed on this basis.
6. The completed system is thoroughly tested (including formal acceptance testing)
and delivered to the customer.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-29-2048.jpg)
![10 Agile Testing: How to Succeed in an Extreme Testing Environment
Cost
Release
Review Progress
2
.
I
d
e
n
t
i
f
y
&
R
e
s
o
l
v
e
R
i
s
k
s
1
.
D
e
t
e
r
m
i
n
e
O
b
j
e
c
t
i
v
e
s
3
.
D
e
v
e
l
o
p
m
e
n
t
&
T
e
s
t
4
.
P
l
a
n
N
e
x
t
I
t
e
r
a
t
i
o
n
2.2 Graphical Overview of the Spiral Model.
7. Where appropriate, ongoing maintenance and test are performed to prevent
potential failures and to maximize system availability.
Figure 2.2 provides a graphical overview of a typical interpretation of the spiral
model.
Although considered to be an improvement over the waterfall approach in terms
of delivering systems that more closely match the customer’s requirements, and
for delivering higher-quality software (achieved in large part by the spiral model,
which encourages early and continued testing of the prototypes), issues existed
regarding the difficulty of estimating effort, timescales, and cost of delivery; the
nondeterministic nature of the cycle of prototype development and testing meant
that it was difficult to bound the duration and effort involved in delivering the final
product.
2.5 Iterative
Iterative models of software development evolved to address issues raised by both
waterfall and spiral approaches, with the goal of breaking large monolithic develop-
ment projects into smaller, more easily managed iterations. Each iteration would
produce a tangible deliverable (typically some executable element of the system
under development).
The Objectory method [7] provides a good example of such an approach. In
1987, while assisting telecommunications company Ericsson AB with its software](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-30-2048.jpg)
![11 Old-School Development and Testing
development efforts, and concerned with the shortcomings of earlier methods, Ivar
Jacobson brought together a number of the development concepts he had been think-
ing about, such as use cases [8], object-oriented design [9], and iterative development,
to create a new approach to developing successful object-oriented applications.
The Objectory method supported innovative techniques for requirements anal-
ysis, visual modeling of the domain, and an iterative approach to managing the
execution of the project. In essence, Objectory would break down a project that
might have been run in a large and inflexible waterfall manner into smaller, more
easily understood, implemented, and tested iterations.
Such an approach brought a number of important benefits for software quality:
왘 Testing could begin much earlier in the project (from the first iteration), enabling
defects to be identified and fixed in a timely manner, with the result that
timescales were not impacted, and that the effort and cost of fixing and retesting
defects were kept low.1
왘 Testing would continue throughout the project (within each iteration), ensuring
that new defects were found and fixed in a timely manner, that newly added
system functionality did not adversely affect the existing software quality, and
verifying that defects found in earlier iterations did not reappear in the most
recent iteration.
왘 The valuable visual metaphor provided by use cases and visual modeling enabled
the developers and the customer to more easily understand the intention of the
system functionality – in effect the customer, analyst, designer, and tester share
a common language and understanding of the system.
왘 Testers discovered that the scenarios described by the use cases could very easily
be used to design and implement effective test cases2
– the actors (people or other
systems) identified in the use cases and their interactions with the system under
development, mapped easily onto the steps and verifications needed to develop
the test scripts.
The Objectory process was organized around three phases:
1. The requirements phase – which involves the construction of three models that
describe in a simple, natural-language manner what the system should do:
컄 The use case model – which documents the interactions between the actors
and the system, which are typically captured using use case diagrams and
natural-language descriptions.
컄 The domain model – which documents the entities within the system, their
properties, and their relationships.
1 It is generally considered that for each phase of the project during which you fail to find a bug, the cost of
fixing it increases by a factor of 10 [4]. In practice, my experience is that this is a conservative estimate.
2 A test case represents the design for a test. A test case is implemented by means of a test script.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-31-2048.jpg)
![12 Agile Testing: How to Succeed in an Extreme Testing Environment
컄 The user interface descriptions – which document the various interfaces
between the actors and the system.
2. The analysis phase – which involves the construction of two models that are a
refinement of the information captured during the previous phase:
컄 The analysis model – which is a refinement of the domain model produced
in the previous phase and which documents behavioral information, control
objects (linked to use cases), and entity and interface objects.
컄 The subsystem descriptions – which partition the system around closely
coupled and similarly behaving objects.
3. The construction phase – which refines the models produced in the analysis
phase. During this phase the following models are generated:
컄 Block models – which represent the functional modules of the system.
컄 Block interfaces – which specify the public operations performed by the
modules.
컄 Block specifications – which are optional descriptions of block behavior using
finite state machines [10].
In its time, Objectory was considered to be a very successful software development
method, and many of its key principles, such as use case analysis and design, continue
to be widely used today.
In 1991, after having worked closely with the Objectory process for several years,
Ericsson AB purchased a major stake in Ivar Jacobson’s company (Objectory Sys-
tems), changing its name to Objectory AB.
In 1995, Objectory AB merged with the Rational Software Corporation, and
shortly thereafter, the Rational Objectory Process version 4.0 was published,
which incorporated elements of Grady Booch’s object-oriented analysis and design
method [11] and Jim Rumbaugh’s object modeling technique (OMT [12]). Much of
the procedural side of the Objectory method (such as use case modeling) was incor-
porated into the Rational Objectory Process, with the addition of many notational
and diagramming elements from the OMT and Booch methods.
Ultimately, through an incremental process of extension and enhancement,
the Rational Objectory Process evolved into the Rational Unified Process (RUP)
version 5.0, which incorporated modeling and design extensions addressing business
engineering, plus best practice guidance on configuration and change management,
data engineering, and user interface design.
The release of version 7 of RUP provides extensive best-practice guidance on
traditional and agile software development and testing methods, such as the ability
tooptionally select an“extreme programming”style of development (see Appendix B),
as well as the means of customizing the RUP framework to support the user’s own
specific agile approaches.
The RUP is covered in further detail in Chapter 3, along with a number of other
agile approaches.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-32-2048.jpg)
![13 Old-School Development and Testing
Plan Acceptance Tests
Plan System Tests
Requirements
Specification
Design
Implementation Unit Testing
System Testing
Acceptance Testing
Integration Testing
Plan Integration Tests
Plan Unit Tests
2.3 The V-Model; Waterfall Phases and Associated Testing Phases.
2.6 Traditional Elements of Test Process
The final section of this chapter reviews the typical elements of a traditional testing
process, focusing in detail on the relationship between the classic model of testing
and the development approaches described in the earlier sections.
Many traditional views of software testing are based on the V-model [4], which
itself is largely based on the waterfall view of software development. The V-model
approach to organizing testing has also been applied to spiral and other models of
software development, producing a number of variants, such as the W-model [13].
Figure 2.3 shows a typical interpretation of the V-model.
The V-model provides a powerful means of assisting testing practitioners to
move testing earlier into the software development life cycle, and to encourage more
frequent testing.
A major tenet of the V-model is that testing can begin as early as the requirements
acquisition phase – with the test manager reviewing the requirements to determine
the resources needed for testing, and with the test analyst or designer reviewing the
requirements to determine testability and identify errors in the requirements (such
as omissions, contradictions, duplications, and items that need further clarification).
As a generalization, we can identify four basic test levels or phases associated
with the V-model approach to testing:3
1. Unit test (also known as developer or component testing) is typically conducted
by the developer to ensure that their code meets its requirements, and is the
3 However, in practice we might also include other variations of the testing phases, such as systems
integration testing (often employed where the application under test has a requirement to interact with
a number of other independent systems), user acceptance testing, and operations acceptance testing.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-33-2048.jpg)
![14 Agile Testing: How to Succeed in an Extreme Testing Environment
lowest level of testing normally identified. Historically, unit testing was a manual
process (often involving a test harness or some other means of simulating other
planned software components that would communicate with the component
under test, but which had not been coded at that point). Today, unit testing is
usually conducted using one of the many developer testing tools that are available
(see, e.g., [14]).
2. Integration test (also known as module testing) is used to demonstrate that the
modules that make up the application under test, interface and interact together
correctly. As a general rule (but clearly dependent on the size and importance
of the project), integration testing is conducted by the developers under the
supervision of the project leader. Where a more formal approach to development
and testing is being followed, possibly on a large or commercially important
project, an independent tester or test team could be involved in conducting
integration testing.
3. System test is employed to establish confidence that the (now completed) applica-
tion under test will pass its acceptance test. During system testing, the functional
and structural stability of the system is examined, as well as the nonfunctional
aspects of the application under test, such as performance and reliability. Typi-
cally, although again dependent on the size and importance of the project, system
testing is conducted by an independent testing team. Often, a customer or user
representative will be invited to witness the system test.
4. Acceptance test (also known as user acceptance test or UAT) is used to ensure
that the application under test meets its business requirements, and to provide
confidence that the system works correctly and is usable before being formally
handed over to the end users. Typically, UAT will be conducted by nominated
user representatives (sometimes with the assistance of an independent testing
representative or team).
The role of regression testing is also worth noting; its purpose is to provide
confidence that the application under test still functions correctly following a new
build or new release of the software (perhaps caused by requests from the customer
for modifications or enhancements to the software, or a change to the environment
in which the software runs, such as a new release of the underlying operating
system).
Within each of the test levels or phases, we can identify a number of common
elements that they all share. In each testing phase the following must be addressed:
왘 Overview of test phase – providing information on the purpose of the testing
phase, its goals, and its characteristics. Information should also be provided
relating this testing phase to the appropriate development phase within the
V-model and to the adjacent testing phases.
왘 Test phase approach and test data requirements – describing the overall approach
to the testing used in this phase (such as white box or black box testing; see [4]),](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-34-2048.jpg)
![15 Old-School Development and Testing
and addressing the format, content, and origin of the data required to successfully
test the software.
왘 Test planning and resources – providing the plan used to drive the testing con-
ducted during this phase, its timescales, milestones, dependencies, risks, and
deliverables, as well as information on the resources needed to complete the
testing successfully (including both the staff and the physical resources, such as
computer equipment).
왘 Roles and responsibilities – specifying the staff required to fulfill the various
roles within this phase (such as test team leader, test analyst, or tester) and their
specific responsibilities (e.g., “the test analyst shall be responsible for designing
and implementing the test scripts required to test the application under test . . . ”).
Issues of reporting, management, and liaison should also be specified.
왘 Inputs and outputs – specifying those artifacts (the items created and/or used
within phases) required as inputs to this phase to ensure successful testing of
the application under test (such as the test plan, the software itself, and the
requirements documentation), artifacts created during this phase (such as test
designs, test scripts, and test result record forms), and artifacts output from this
phase (such as the tested software, completed test result record forms, and the
test summary report).
왘 Specific test techniques for this test phase – describing any specific testing tech-
niques (such as boundary analysis, equivalence partitioning, or state transition
analysis; see [4]) or tools to be used within this testing phase such as test execution
tools; see [15].
왘 Reusable assets – providing test practitioners with access to standard reusable
assets (such as test plan, test script, and test summary report templates) that
are shared across the project (or even across an organization). These assets can
ensure that significant project time, effort, and cost are saved by preventing
different practitioners on different projects from reinventing different versions
of the same artifacts again and again. Standardization also makes it easier for
staff to move between projects without having to relearn a new and different set
of project documentation.
The preceding information is traditionally recorded in one or more testing docu-
ments (usually within the test plan document and the test specification document).
Although this approach to software testing has been widely adopted and used, as
with the traditional development processes, this classic view of testing process has
its critics:
왘 A key criticism leveled against the approach is that it is underpinned by the
V-model, which is itself based on the frequently criticized waterfall model of
software development. The relevance of the classic view of test process is often
questioned when applied to more contemporary, agile views of software develop-
ment.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-35-2048.jpg)
![3 Agile Development and Testing
Nanos gigantum humeris insidentes –
We are but dwarfs standing upon the shoulders of giants.
Bernard of Chartres
3.1 Introduction
The long history of software development is too frequently characterized by failure
rather than by success. When you consider that the practice of software development
and testing has spanned two centuries (and arguably three or more centuries1
), it
seems incredible that such a high proportion of projects are unsuccessful. One highly
respected industry report, for example, suggested that as many as 76% of all software
projects fail to come in on time, to budget, or to customer satisfaction [2].
Growing dissatisfaction with the failure of traditional heavyweight approaches
caused a number of workers in the field of software development to begin to question
the role of ponderous, inflexible, and frequently ineffective development processes.
From the 1980s onward, new lightweight or agile approaches to developing and
testing software in an effective and efficient manner began to appear, which chal-
lenged the need for cumbersome and ineffectual process. Such approaches frequently
focused on the need for good communication in projects, the need to adopt smaller,
more easily managed iterations, and the need to be responsive to changing customer
requirements.
This chapter provides a review of the most prominent agile methods that have
been used to develop and test software. Specifically, the agile approaches covered in
this chapter include the following:
왘 Rapid Application Development (RAD),
왘 Extreme Programming (XP),
왘 the Dynamic Systems Development Method (DSDM), and
왘 Scrum.
Each of these agile approaches is discussed at a relatively high level in this
chapter; greater detail is presented in Appendices A through D, respectively.
1 If we include the patterns developed for guiding the actions of weaving machines, for example, or even
the astronomical software druids ran on their early silicon and granite hardware systems.
18](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-38-2048.jpg)
![19 Agile Development and Testing
The chapter concludes with a brief overview of the key features of a number of
other agile methods and approaches, including
왘 the Enterprise Agile Process (previously XBreed),
왘 Ruby on Rails (RoR),
왘 Evolutionary Project Management (Evo),
왘 the Rational Unified Process (RUP),
왘 the Essential Unified Process (EssUP), and
왘 the Software Process Engineering Metamodel (SPEM).
Inevitably, this is a snapshot of the agile methods because it is by necessity a very
fast-moving subject.
3.2 Rapid Application Development
The RAD first appeared in the 1980s, when James Martin developed the approach in
response to increasing dissatisfaction with the failure of earlier methods such as the
waterfall model of software development [5].
These earlier approaches were characterized by being highly prescriptive, with
developers following an inflexible series of development phases in which require-
ments were gathered early in the process and then set in stone throughout the rest of
the project. Typically, customer involvement was limited to the initial requirements
capture and final acceptance testing, resulting in an unacceptably high number of
delivered systems that did not match the actual customer needs (which had almost
certainly changed since they had been first documented anyway). Cost and time
overruns were the norm for such projects and, since much of the testing was left to
the later phases, the systems were frequently delivered with major quality issues.
Initially inspired by the work of other prominent workers in the field of devel-
opment and testing, such as Barry Boehm, Brian Gallagher, and Scott Schults, and
following a gestation period of several years, Martin’s thoughts on rapid software
development were finally formalized as RAD in his 1990 book, Rapid Application
Development [16].
The key goals of RAD are
왘 high-quality systems,
왘 fast development and delivery, and
왘 low costs.
RAD seeks to break down the approach taken in monolithic waterfall projects into
smaller iterative steps, increasing the opportunities for the customer to be involved
in the development and to be exposed to earlier prototypes and working increments
of the developing system. In fact, the development of software prototypes is a key
aspect of RAD, providing a means of exploring the customer needs for the system
through informal testing and managing customer expectations of how the final
delivered system should look and perform.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-39-2048.jpg)
![20 Agile Testing: How to Succeed in an Extreme Testing Environment
RAD proved to be of benefit over traditional development approaches in a number
of areas:
왘 RAD’s iterative approach to developing software meant that testing could begin
earlier in the development process and could continue more frequently through-
out the project. This approach significantly reduced the risk of late identification
of serious defects and the associated cost overruns and late delivery frequently
seen in waterfall projects.
왘 Closer customer involvement in the development process, with early opportuni-
ties to test how well the software met customer needs using the prototypes, meant
there were less show-stopping surprises when the system was finally delivered.
왘 Accepting that requirements would no longer be set in stone at the very begin-
ning of the project and that changes could be managed effectively through-
out the development using requirements planning workshops and joint applica-
tion design workshops, helped ensure the delivered software would more closely
match customer expectations.
왘 Tighter project management of development priorities, costs, and timescales
through the use of techniques such as time boxing [17] kept project progress on
track and controlled the extent that the development could get out of control.
On the down side, for many practitioners who followed more traditional software
development models, RAD gained the reputation of being an excuse for “hacking”
or “opportunistic coding,” as it has also been called [18]. It is possible that, as one
of the earliest agile methods, RAD may have been perceived as having less rigor
than the more established approaches. Also, RAD’s focus on developing a series of
rapid prototypes, many of which inevitably would not be carried forward into the
final deliverable, was often blamed for wasting time and effort and jeopardizing
progress. Finally, the process of prototyping was often poorly implemented due to
a weak understanding of what prototyping actually involved [19], leading to a poor
perception of the technique.
Despite some suspicion from the defenders of the more traditional development
methods, RAD arguably set the scene for the development of a number of the later
agile methods.
Appendix A contains further details of the rules and practices of RAD.
3.3 Extreme Programming
In the early 1990s, Kent Beck, a practitioner in the field of software development, had
begun to consider how the process of developing software could be made simpler
and more efficient. In March 1996 Kent embarked upon a project with a major
automotive customer that would employ a number of the software development and
testing concepts that he had been considering; the result was the genesis of Extreme
Programming (XP [20]).](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-40-2048.jpg)
![22 Agile Testing: How to Succeed in an Extreme Testing Environment
The DSDM is founded upon nine key principles:
1. Active user involvement is imperative.
2. DSDM teams must be empowered to make decisions.
3. The focus is on frequent delivery of products.
4. Fitness for business purpose is the essential criterion for acceptance of deliver-
ables.
5. Iterative and incremental development is necessary to converge on an accurate
business solution.
6. All changes during development are reversible.
7. Requirements are baselined at a high level.
8. Testing is integrated throughout the life cycle.
9. A collaborative and cooperative approach among all stakeholders is essential.
These principles were framed by combining the agile best practices and experi-
ences of the DSDM consortium members. The first draft of the DSDM framework
was delivered in January 1995, followed in February that year by formal publication
of the framework [21].
Within its overall iterative approach, a DSDM project is structured into three
distinct phases:
1. Preproject phase – this 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 definition of the business
problem to be addressed, budget and resourcing, outline scope and plans for the
feasibility study, and a decision whether or not to proceed with the project.
2. Project life cycle phase – this phase combines both sequential and iterative stages,
which drive the incremental development of the system. Following the initial
feasibility and business study stages, the project iterates through the functional
model iteration, design and build iteration, and implementation stages.
3. Postproject phase – this phase covers postdelivery activities such as maintenance,
enhancements, and software fixes, and is used to ensure the ongoing effective
and efficient operation of the delivered system.
In terms of its continuing adoption and use, DSDM seems to have been more
successful at being accepted by senior management than earlier agile approaches
such as RAD due to the perception that it represents a more mature and formal agile
method. This perception is further reinforced as a result of the frequent integration
of DSDM and the PRINCE2 (PRojects IN Controlled Environments) project manage-
ment method [22]. As a result, more conservative senior managers have been more
receptive to the use of DSDM on larger/higher-profile projects with the result that a
substantial and vigorous user population has been established around the globe.
The DSDM has also proven to be popular with development and testing prac-
titioners, who have continued to refine and enhance the method; since its initial](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-42-2048.jpg)
![23 Agile Development and Testing
publication in 1995, DSDM has continued to evolve, incorporating new best prac-
tices and technologies wherever appropriate.
Appendix C contains further details of the principles and practices of DSDM.
3.5 Scrum
Scrum is a project management method for agile software development and testing
that enables the creation of self-organizing teams by encouraging co-location of all
team members (including customer representatives) combined with effective verbal
communication among all team members and across all disciplines that are involved
in the project.
A key principle of Scrum is the recognition that during a project, the customers
are likely to change their minds frequently about what they want and need (often
called requirements churn), and that such customer needs cannot be addressed
successfully in a traditional predictive or planned manner. As such, Scrum adopts
an empirical approach – accepting that the problem cannot be fully understood or
defined, focusing instead on maximizing the team’s ability to deliver quickly and
respond to emerging requirements.
In terms of the genesis of Scrum, as early as 1986 Takeuchi and Nonaka [23]
had observed that projects employing small, cross-functional teams were typically
the most successful, and they coined the phrase “rugby approach” to describe the
phenomenon. The first explicit reference to Scrum2
in the context of software devel-
opment came in 1990 in work by DeGrace and Stahl [24].
In the early 1990s, work on agile methods by Ken Schwaber and Jeff Sutherland, at
their respective companies Advanced Development Methods and Easel Corporation,
led Sutherland and Schwaber to jointly present a paper at the 1996 International
Conference on Object-Oriented Programming, Systems, Languages, and Application
describing Scrum [25]. Schwaber and Sutherland collaborated during the following
years to further develop and document their experiences and industry best practices
into what is now known as Scrum.
In 2001, Ken Schwaber teamed up with Mike Beedle to write up the method in
Agile Software Development with SCRUM [26].
A major factor in the success of Scrum projects is the drive for efficient commu-
nications, with techniques such as daily short focused stand-up meetings combined
with explicit team roles (e.g., Pig and Chicken; see Appendix D) to manage who may
contribute to the meetings and in what manner.
Although Scrum was originally intended to be used for the management of
software development projects, it can be employed in running software maintenance
teams or as a program management approach: Scrum of Scrums.
Appendix D contains further details of the rules and practices of Scrum.
2 Scrum: a play in the ball game rugby in which two groups of players mass together around the ball and,
with their heads down, struggle to gain possession of the ball. Typically held following an illegal forward
pass.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-43-2048.jpg)
![24 Agile Testing: How to Succeed in an Extreme Testing Environment
3.6 Other Agile Methods
This section provides a high-level overview of the key features of a number of other
agile methods and approaches to software development and testing. By necessity,
this is only a snapshot of the current popular methods and does not seek to be
a comprehensive catalog of all agile approaches. Because this subject evolves so
quickly, it is recommended that the reader also refer to [26] as a useful source of
updates on agile methods.
3.6.1 The Enterprise Agile Process (formerly XBreed)
Developed by Mike Beedle with the goal of developing “reusable software in record
time,” this twenty-first-century agile approach combines a number of best practices
from other agile methods, such as XP and Scrum. Specifically, EAP [28] employs best
practices from Scrum as the basis of its management framework and incorporates a
subset of XP techniques for its development process.
A key feature of the method is the use of design patterns to create reusable objects;
EAP creates a library of components that can be easily reused in new software projects
to save time, effort, and cost of development and testing, while improving quality by
the reuse of “tried and tested” components.
The EAP development process promotes the use of well-trained, skilled, and
experienced practitioners to populate its teams, and encourages the use of effective
knowledge transfer between team members, which, combined with a low communi-
cation overhead, helps keep the project running smoothly and efficiently.
3.6.2 Ruby on Rails
Created by David Heinemeier Hansson from his earlier work on the Basecamp web-
based project management tool [29], Ruby on Rails (RoR [30]) is an open-source web
framework that is optimized for “programmer happiness and sustainable productiv-
ity.” Typically used by developers for relatively short client-driven web development,
and often referred to as “Rails,” RoR use is guided by two key principles:
왘 Convention over configuration (CoC) – In effect development by exception, the
benefit of CoC is that only the unconventional aspects of the application need to be
specified by the developer, resulting in reductions in coding effort. For example,
if the developer creates a class “Part” in the model, the underlying database table
is called “Parts” by default. It is only if one deviates from this convention, such
as calling the table “parts_on_hand,” that specific code needs to be written that
utilizes these names.
왘 Don’t repeat yourself – RoR promotes an approach where information is located
in a single, unambiguous place. For example, using the ActiveRecord module of
RoR, the developer does not need to explicitly specify database column names in
class definitions. Instead, RoR can retrieve this information from the database.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-44-2048.jpg)
![25 Agile Development and Testing
Using the model-view-controller architecture [31] for organizing application
programming, RoR incorporates a number of tools:
왘 scaffolding, for simplifying the generation of basic Web site models and views;
왘 WEBrick, a simple RoR web server; and
왘 Rake, a simple build system.
By providing these tools combined with an agile development philosophy, RoR
can be seen as an example of a highly agile integrated development environment.
First released to the public in July 2004, RoR continues to find supporters in the
web developer community with an impressive list of adopters (since 2007 RoR has
been shipped by Apple with MacOS X v10.5 Leopard, for example).
3.6.3 Evolutionary Project Management
Developed by Tom and Kai Gilb, Evolutionary Project Management (Evo [32]) is
a twenty-first-century agile project management method whose focus is on earlier
delivery of critical results and on-time delivery of deadlined results. Evo is claimed
to be able to provide more control over software quality, project performance, and
project costs than more traditional project management methods.
Evo is particularly suited to developing large-scale software systems, involving
complex technology and in rapidly moving environments. Evo aims to be highly
responsive and adaptable to unforeseen circumstances while delivering rapid results.
Evo follows ten key process principles:3
1. Real results, of value to real stakeholders, will be delivered early and frequently.
2. The next Evo delivery step must be the one that delivers the most stakeholder
value possible at that time.
3. Evo steps deliver the specified requirements, evolutionarily.
4. It is impossible to know all the right requirements in advance, but it is possible to
discover them more quickly by attempts to deliver real value to real stakeholders.
5. Evo is holistic systems engineering; all necessary aspects of the system must be
complete and correct, and delivered to a real stakeholder environment. It is not
only about programming, it is about customer satisfaction.
6. Evo projects will require an open architecture, because project ideas will change
as often as needed to really deliver value to the stakeholders.
7. The Evo project team focuses their energy, as a team, toward success in the
current Evo step. They succeed or fail in the current step together. They do
not waste energy on downstream steps until they have mastered current steps
successfully.
8. Evo is about learning from hard experience, as fast as possible – what really
works and what really delivers value. Evo is a discipline to make teams confront
project problems early, but one that delivers progress quickly when provably,
the team have got it right.
3 Sincere thanks to Tom and Kai Gilb for allowing me to reproduce this information.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-45-2048.jpg)
![26 Agile Testing: How to Succeed in an Extreme Testing Environment
9. Evo leads to early, and on-time, product delivery – both because of selected early
priority delivery and because the team learns to get things right early.
10. Evo should allow teams to validate new work processes and get rid of bad ones
early.
Benefits cited by Evo users include reducing the duration and cost of require-
ments capture by 75% over traditional methods, reducing the integration effort to
upgrade from a previous code platform to a new code platform from hours to min-
utes, and improvements in the motivation, enthusiasm, and morale of developers
and testers, leading to significantly higher staff retention.
The success of Evo can also be measured by the number of high-profile users
(such as IBM, HP, and Microsoft) that have been involved in learning and using the
method.
3.6.4 Rational Unified Process
Originally developed by Ivar Jacobson, Grady Booch, and Jim Rumbaugh at Rational
Software Corporation, RUP is a use case–driven [7] iterative software engineering
process that employs the Unified Modeling Language (UML) notation [33] to incre-
mentally develop and deliver software. RUP provides industry best practice guidance
on software development and testing to its users through a web browser inter-
face, allowing the information to be accessed in a simple and easily distributed
manner.
The RUP iterations are organized under a number of phases – inception, elab-
oration, construction, transition, and production – with development and testing
activities grouped as a series of disciplines that run across the phases. These typically
include business modeling, requirements, analysis and design, implementation, test,
deployment, operations and support, configuration and change management, project
management, environment, and infrastructure management.
RUP provides comprehensive information on all aspects of software development,
including project roles and responsibilities, project planning and management, tasks
and timescales, inputs and outputs, testing techniques and approaches, reusable
project templates (such as test plan and test script templates), metrics, and guidance
on process improvement.
RUP explicitly supports agile approaches by providing a customizable metamodel
that allows users to select from the RUP best practices to create and maintain their
own subset of agile best practices. RUP also provides access to predefined agile
customizations, such as its XP process plug-in.
With its early origins in Ivar Jacobson’s 1990s Objectory process [7], the devel-
opment of RUP has been a highly inclusive process, and it has drawn from many
sources including the experience of major industry experts, special interest groups,
industry standards and guidelines, and the experiences of many thousands of ordinary
practitioners.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-46-2048.jpg)
![27 Agile Development and Testing
Over the years, RUP has spawned a number of other agile methods and initiatives,
such as the EssUP [34] and the Object Management Groups SPEM.
3.6.5 The Essential Unified Process
The EssUP [34] is a continued development of the work begun in RUP by process
guru Ivar Jacobson, which identifies and promotes the use of a number of essential
practices that include use cases, iterative development, architecture-driven design,
team practices, and process practices, plus process improvement (through Capability
Maturity Model Integration [35]) and agile development.
Adoption and use of EssUP are accelerated through the use of a set of “playing
cards” – concise ready reference cards documenting the process best practices in a
simple and highly accessible manner. Chapter 5 contains examples of these cards,
and Figure 5.1 shows the Test Case and Test Results cards.
EssUP appears to be gaining in popularity and use, with both IBM and Microsoft
incorporating its best practices into their respective process product offerings.
3.6.6 The Software Process Engineering Metamodel
SPEM [3] is, as its name suggests, a process metamodel that allows users to develop
and maintain their own specific development and testing process.
SPEM is administered by the Object Management Group (OMG [36]) and based
on the RUP metamodel, which the Rational Corporation donated to OMG for the
purpose of supporting the development of a widely available open-source software
process engineering metamodel.
Employing the UML notation [33], SPEM provides facilities for individual devel-
opment and testing practitioners to create their own specific development method
that incorporates those process elements appropriate to their own particular devel-
opment needs and requirements.
3.7 Summary
Having worked in the software business for more than thirty years, I must admit
to wondering if anyone will ever be completely satisfied with a particular means of
developing and testing software.
It seems that, since the earliest days of process development, there have been
practitioners who have either thought the resulting process was too lightweight or
too heavyweight, that it guided them to do their job or constrained their creativity,
that it gave them the freedom to use industry best practice or clipped their developer
and/or tester wings.
I have often wondered if a major issue driving the development of new agile
methods is a desire for IT practitioners to express their own individuality and their
own creativity; even where perfectly usable and successful agile methods like Scrum](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-47-2048.jpg)
![4 From Waterfall to Evolutionary Development and Test
Tom Gilb and Trond Johansen
SYNOPSIS
Evolutionary Development (Evo) focuses on early delivery of high value to stakeholders and
on obtaining and utilizing stakeholder feedback. This case study describes, from a project
manager’s viewpoint, the results that one organization rapidly achieved after switching from
using a waterfall approach to Evo. The major benefits of adopting an Evo approach come
from reducing the duration of the requirements phase from four to five weeks down to just
one week, and from paying greater attention to the quality requirements as opposed to the
previous practice of concentrating solely on the required functionality, resulting in a happier
workforce, happier clients, and more business.
4.1 Introduction
My name is Tom Gilb and I am an independent testing consultant and author of
Competitive Engineering: A Handbook for Systems & Software Engineering Man-
agement using Planguage (2005), Principles of Software Engineering Management
(1988), and Software Inspection (1993). My book Software Metrics (1976) coined
the term and was used as the basis for the Software Engineering Institute Capability
Maturity Model Level Four (SEI CMM Level 4 [37]). My most recent interests are
development of true software engineering and systems engineering methods.
In 1997 Kai Gilb and I published a book entitled Evo: The Evolutionary Project
Management and Product Development Handbook, describing an agile software
development and testing project management method [32]. Evo is an iterative
method in which a series of small delivery steps are taken until the project goals are
reached and the software delivered. Key differences between Evo and other project
management methods include an emphasis on achieving the requirements over slav-
ishly following formal processes, and the focus on ensuring that testing starts early in
the process, is conducted in each of the steps, and continues throughout the project.
This case study will focus on the adoption and use of the Evo method in the devel-
opment of the Confirmit
√
product from Oslo-based company Confirmit AS, which
is where co-author Trond Johansen works as the head of project management.
31](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-51-2048.jpg)
![32 Agile Testing: How to Succeed in an Extreme Testing Environment
Specifically, this case study focuses on the role and use of Evo in reducing the
integration effort and timescales for developments and enhancements made to the
Confirmit
√
product, as compared with the previously used waterfall-based [5] devel-
opment process.
4.2 Overview of the Testing Challenge
Confirmit
√
is a powerful web-based software package that enables organizations
to gather, analyze, and report on key business information across a broad range of
commercial applications. Some twenty staff (including a quality assurance team of
three people) work in the Confirmit AS research and development department and
have responsibility for developing the core Confirmit
√
functionality, as well as for
developing custom bespoke modules for specific clients.
Early in the company’s history, when Confirmit AS had just a few clients, the
development process was fairly ad hoc and customer-driven. Changes to the software
were made on an almost daily basis, driven by client feedback, and while this deliv-
ered stakeholder value quickly, the process also resulted in numerous defects, long
working hours, and poor control of the software development and testing process.
As the Confirmit
√
client base grew, Confirmit AS was faced with the need to
become more effective and efficient in its development and testing of the product; it
was clear that a more formal process was needed.
Initially, Confirmit AS looked to adopt a waterfall approach, incorporating pro-
cess improvement via the Capability Maturity Model (CMM [37]). After following a
waterfall approach for a number of years, a number of issues were identified:
왘 Risk discovery and mitigation was delayed until the later stages of the project.
왘 Document-based verification was postponed until the later stages of the project.
왘 There was dissatisfaction with the need to stipulate unstable requirements too
early; requirements change is perceived as a bad thing in waterfall.
왘 Operational problems were discovered far too late in the process (typically at
acceptance testing).
왘 There were lengthy modification cycles and too much rework and retesting.
왘 Most important, the requirements were nearly all focused on functionality, not
on the quality attributes of the system.
With increasing dissatisfaction with their waterfall approach, Confirmit AS began
to work closely with Tom and Kai Gilb to roll out and adopt an Evo approach in order
to improve their development process for Confirmit
√
. In particular, three key goals
were identified:
왘 Reducing the integration effort – that is, the amount of effort for each developer
to get the latest build to work on his or her workstation so that they were able to
code against the latest code platform;](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-52-2048.jpg)
![34 Agile Testing: How to Succeed in an Extreme Testing Environment
In terms of Evo cycle time, a one-week-long Evo step was adopted in which the
key activities were as follows:
왘 On the Friday:
컄 The Project Manager (PM) delivers the detailed plan for the next week’s
version of the software (let’s call it Version N) to the customer Chief
Technical Officer (CTO) prior to attending a weekly project management
meeting.
컄 The CTO reviews and approves or rejects the design and records their com-
ments.
컄 The PM and CTO attend the weekly project management meeting to discuss
the Version N detailed plan and review CTO comments.
컄 The developers focus on general maintenance and documentation tasks.
컄 The QA team runs final build and setup for that week’s developed version (let’s
call it Version N-1), installs setup on test servers, and performs initial crash
test1
of Version N-1 prior to its release.
왘 On the Monday:
컄 The developers first generate the tests required to validate Version N and then
begin development of the code.
컄 The QA team reviews the results of the continuous integration (CI) process
and reviews test plans and tests for Version N.
컄 The users begin to use Version N-1 and compile feedback for the developers.
왘 During Tuesday and Wednesday:
컄 The developers continue to generate the tests required to validate Version N
and develop the associated code.
컄 The developers meet with the users to discuss the feedback from using
Version N-1.
컄 Incorporating the feedback from the users, the developers continue to gen-
erate the tests required to validate Version N and develop the associated
code.
컄 The QA team reviews the results of the CI process and reviews test plans and
tests for Version N.
왘 On the Thursday:
컄 The developers complete the final tests for Version N, code, and execute the
tests. The developers also complete the graphical user interface tests for the
previous week’s version of the software (let’s call this Version N-2).
컄 The QA team reviews the results of the CI process and reviews test plans and
tests for Version N.
1 A testing technique used to determine the fitness of a new build or release of the application under test
to undergo further, more thorough testing [4].](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-54-2048.jpg)
![Cardinal de Granvelle (Collection de Documents inédits, Paris, 1841-52); Furnivall,
Ballads from Manuscripts (Ballad Society, London, 1868); Four Supplications of the
Commons, and Thomas Starkey, England under Henry VIII. (Early English Text
Society, 1871); Strype, Ecclesiastical Memorials and Life of Cranmer (Oxford
edition, 26 vols. 1820, etc.); Liturgies of Edward VI. (Parker Society, Cambridge,
1844); Stow Annals (London, 1631).
Later Books in addition to those given on p. 313: Pollard, England under Protector
Somerset (London, 1900); Burnet, History of the Reformation (Oxford edition,
1865); Dixon, History of the Church of England (London, 1893); Gasquet and
Bishop, Edward VI. and the Book of Common Prayer (London, 1890). Cambridge
Modern History, ii. xiv.
[476] Pollard, Cambridge Modern History, ii. 474.
[477] These Injunctions, and the Articles of Inquiry which interprets them, are
printed in Strype, Ecclesiastical Memorials, etc. (Oxford, 1822) II. i. pp. 74-83.
[478] Cranmer, Miscellaneous Writings and Letters (Parker Society Cambridge,
1846), p. 128.
[479] English Historical Review for 1904 (January), pp. 98 ff.
[480] This Act, entitled Act against Revilers, and for receiving in both Kinds, is
printed in Gee and Hardy, Documents, etc. p. 322.
[481] Gee and Hardy, Documents, etc. p. 328.
[482] Ecclesiastical Memorials, etc. II. i. p. 133. It is printed in The Two Liturgies,
with other Documents set forth by Authority in the Reign of King Edward the Sixth
(Parker Society, Cambridge, 1844), p. 1.
[483] The book is printed in The Two Liturgies, etc., of the Parker Society, pp. 9 ff.
[484] Gee and Hardy, Documents, etc. pp. 358 ff.
[485] Mr. Pollard (Cambridge Modern History, ii. pp. 478, 479) thinks that the
influence of these foreign divines on the English Reformation has been overrated;
and he is probably correct so far as changes in worship and usages go. His idea is
that the English Reformers followed the lead of Wiclif, consciously or
unconsciously, rather than that of continental divines; but if the root-thought in all
Reformation theology be considered, it may be doubted whether Wiclif could
supply what the English divines had in common with their continental
contemporaries. “Wiclif, with all his desire for Reformation, was essentially a
mediæval thinker.” The theological question which separated every mediæval
Reformer from the thinkers of the Reformation was, How the benefits won by the
atoning work of Christ were to be appropriated by men? The universal mediæval
answer was, By an imitation of Christ; while the universal Reformation answer
was, By trust in the promises of God (for that is what is meant by Justification by](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-56-2048.jpg)
![Faith). In their answer to this test question, the English divines are at one with the
Reformers on the Continent, and not with Wiclif.
[486] Pollard, England under Protector Somerset (London, 1900).
[487] “Tulchan is a calf skin stuffed with straw to cause the cow to give milk. The
Bishop served to cause the bishoprick to yeeld commoditie to my lord who
procured it to him.” Scott’s Apologetical Narration of the State and Government of
the Kirk of Scotland since the Reformation (Woodrow Society, Edinburgh, 1846), p.
25.
[488] The book is printed in The Two Liturgies, with other Documents, etc. (Parker
Society), p. 187.
[489] Gee and Hardy, Documents, etc. p. 371.
[490] Compare The Two Liturgies, etc. (Parker Society) p. 283.
[491] Ibid. pp. 92, 279.
[492] Gee and Hardy, Documents, etc. p. 269.
[493] Original Letters relative to the English Reformation (Parker Society,
Cambridge, 1847), ii. 566.
[494] Original Letters, etc. (Parker Society) ii. 568, Macronius to Bullinger (August
28th, 1550).
[495] Sources in addition to those on pp. 351: Epistolæ Reginaldi Poli, S. R. E.
Cardinalis, 5 vols. (Brixen, 1744-57); Chronicle of Queen Jane and of two years of
Queen Mary, and especially of the Rebellion of Sir Thomas Wyat, written by a
Resident in the Tower of London (Camden Society, London, 1850); Garnett, The
Accession of Queen Mary; being the contemporary narrative of Antonio Guaras,
etc. (London, 1892).
Later Books: Stone, History of Mary I., Queen of England (London, 1901); Ranke,
Die römischen Päpste (Berlin, 1854); Hume, Visit of Philip II. (1554) (English
Historical Review, 1892); Leadam, Narrative of the Pursuit of the English Refugees
in Germany under Queen Mary (Transactions of Royal Historical Society, 1896);
Wiesener, The Youth of Queen Elizabeth, 1533-58 (English translation, London,
1879); Zimmermann, Kardinal Pole sein Leben und seine Schriften (Regensburg,
1893).
[496] Gee and Hardy, Documents, etc. p. 373.
[497] The Act of Parliament is printed in Gee and Hardy, Documents, etc. p. 377.
[498] Philip’s marriages had this peculiarity about them, that his second wife
(Mary) had been betrothed to his father, and his third wife had been betrothed to
his son.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-57-2048.jpg)
![[499] Strype, Memorials of Queen Mary’s Reign, III. ii. 215.
[500] Gee and Hardy, Documents, etc. p. 385.
[501] In the days of Henry VIII., Bishop Gardiner had published a book under this
title, in which the papal jurisdiction in England was strongly repudiated. Someone,
probably Bale, when Gardiner was aiding the Queen to restore that supremacy,
had translated the book into English, and had printed at the bottom of the title-
page, “A double-minded man is inconstant in all his ways.”
[502] Gee and Hardy, Documents, etc. p. 384, The Act de hæretico comburendo
will be found on p. 133.
[503] Ibid. p. 380.
[504] Bonner’s Articles of Inquiry are printed in Strype’s Historical Memorials,
Ecclesiastical and Civil, etc. III. ii. p. 217.
[505] Gairdner’s The English Church in the Sixteenth Century, etc. (London, 1902)
p. 339.
[506] Strype, Memorials, Ecclesiastical and Civil, etc. III. i. 221, 223.
[507] Ibid. III. ii. 556.
[508] Strype, Memorials, Ecclesiastical and Civil, etc. III, i. 222, III. ii, 224.
[509] Calendar of State Papers, Domestic Series, of the Reign of Elizabeth, 1601-
3; with Addenda, 1547-65 (London, 1870), p. 483.
[510] An account of Cranmer’s trial is given in Foxe, Acts and Monuments
(London, 1851), iii. 656 ff. The process is in Cranmer’s Miscellaneous Writings and
Letters (Parker Society), pp. 541 ff.
[511] Cranmer’s Works, ii. 447 ff.
[512] Works, ii. pp. 445-56.
[513] Miscellaneous Writings, etc. (Parker Society) p. 563.
[514] Pollard, Cranmer, pp. 367-81.
[515] Calendar of State Papers and MSS. existing in the Archives and Collections
of Venice, 1555-56, p. 386.
[516] Pollard, Cranmer, p. 328.
[517] There are few more pathetic documents among the State Papers than those
thus catalogued:
“King Philip and Queen Mary to Cardinal Pole, notifying that the Queen has been
delivered of a Prince.”](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-58-2048.jpg)
![“Passport signed by the King and Queen for Sir Henry Sydney to go over to the
King of the Romans and the King of Bohemia, to announce the Queen’s happy
delivery of a Prince.”
There are several such notifications all ready for the birth which never took place.
Calendar of State Papers, Domestic Series, of the reigns of Edward VI., Mary,
Elizabeth, 1547-80 (London, 1856), p. 67.
[518] Sources: Calendar of State Papers, Elizabeth, Foreign (London, 1863, etc.);
Calendar of State Papers relating to Scotland and Mary Queen of Scots
(Edinburgh, 1898, etc.); Calendar of State Papers, Hatfield MSS. (London, 1883);
Calendar of State Papers, Venetian, 1558-80 (London, 1890); Calendar of State
Papers, Spanish, 1558-67 (London, 1892); Weiss, Papiers d’état du Cardinal
Granvelle, vols. iv.-vi. (Paris, 1843-46); Bullarium Romanum, for two Bulls—the one
of 1559 (i. 840) and the one deposing Elizabeth (ii. 324); A Collection of Original
Letters from the Bishops to the Privy Council, 1564 (vol. ix. of the Camden
Miscellany, London, 1893); Calvin’s Letters (vols. xxxviii.-xlviii. of the Corpus
Reformatorum); Zurich Letters (two series) (Parker Society, Cambridge, 1853);
Liturgies and occasional Forms of Prayer set forth in the Reign of Queen Elizabeth
(Parker Society, Cambridge, 1847); Dysen, Queene Elizabeth’s Proclamation
(1618).
Later Books: Creighton, Queen Elizabeth (London, 1896); Hume, The Courtships of
Queen Elizabeth (London, 1896); and The great Lord Burghley (London, 1898);
Philippson, La contre-révolution religieuse (Brussels, 1884); Ruble, Le Traité de
Cateau-Cambrésis (Paris, 1889); Gee, The Elizabethan Clergy (Oxford, 1898); and
The Elizabethan Prayer-Book and Ornaments (London, 1902); Tomlinson, The
Prayer-Book, Articles and Homilies (London, 1897); Hardwick, History of the
Articles of Religion (Cambridge, 1859); Lorimer, John Knox and the Church of
England (London, 1875); Neal, History of the Puritans (London, 1754); Parker The
Ornaments Rubric (Oxford, 1881); Shaw, Elizabethan Presbyterianism (English
Historical Review, iii. 655); Cambridge Modern History, ii. 550 ff.; Frere, History of
the English Church in the Reigns of Elizabeth and James 1558-1625 (London,
1904).
[519] Calendar of Letters and State Papers relating to English Affairs, preserved
principally in the Archives of Simancas (London, 1892), i. p. 7.
[520] Ibid. p. 89. In the same letter the Bishop blames the instructions of the
“Italian heretic friars,” i.e. Peter Martyr Vermigli and Ochino; cf. p. 81.
[521] Ibid. pp. 1, 4, 5, etc.
[522] Ibid. pp. 3, 77.
[523] Calendar of Letters and State Papers relating to English Affairs, etc.
Introduction, p. lv.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-59-2048.jpg)
![[524] Calendar of Letters and State Papers relating to English Affairs, etc. p. 62.
[525] Ibid. pp. 39, 67; cf. 83.
[526] Cf. Device in Gee’s Elizabethan Prayer-Book, p. 197.
[527] Strype, Annals of the Reformation and Establishment of Religion, etc.
(Oxford, 1824) I. ii. 389.
[528] Gee and Hardy, Documents, etc. p. 416.
[529] Goderick’s Divers Points of Religion contrary to the Church of Rome is
printed by Dr. Gee in the appendix to his Elizabethan Prayer-Book and Ornaments
(London, 1902), pp. 202 ff.; the sentence quoted is on p. 205; the document is
also in Dixon’s History of the Church of England, v. 28.
[530] Venetian State Papers, 1558-80, 1.
[531] Calendar of Letters and State Papers relating to English Affairs, preserved
chiefly in the Archives of Simancas, i. 17, 25.
[532] Calendar of State Papers, Domestic Series, of the Reigns of Edward VI.,
Mary, and Elizabeth (London, 1856), i. 123.
[533] Calendar of Letters and State Papers relating to English Affairs, preserved
chiefly in the Archives of Simancas, i. 25.
[534] Ibid. pp. 7, 12.
[535] English Historical Review for July 1903, pp. 517, ff.; Dublin Review, Jan.
1903; The Church Intelligencer, Sept. 1903, pp. 134, ff.
[536] Cf. Tomlinson, “Elizabethan Prayer-Book: chronological table of its
enactment,” in Church Gazette for Oct. 1906, p. 233.
[537] Dublin Review, Jan. 1903, p. 48 n: “Ad quem eundem locum (House of
Commons) isti convenerunt (ut communis fertur opinio) ad numerum ducentorum
virorum, et non decem catholici inter illos sunt reperti.”
[538] Zurich Letters, i. 10 (Parker Society, Cambridge, 1842); cf. Calendar of
Letters and State Papers relating to English Affairs, preserved principally in the
Archives of Simancas, 1558-67, p. 33: “To-morrow it (the Bill) goes to the Upper
House, where the bishops and some others are ready to die rather than consent to
it.”
[539] For “Il Schifanoya” and his trustworthiness, cf. Calendar of State Papers,
Venetian, 1558-80, Preface viii.
[540] Ibid. p. 52.
[541] Canon Dixon (History of the Church of England, v. 67) declares that the
phrase “Supreme Head” was not in the Bill. He has overlooked the fact that Heath](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-60-2048.jpg)
![in his speech against it quotes the actual words used in the proposed Act: “I
promised to move your honours to consider what this supremacy is which we go
about by virtue of this Act to give to the Queen’s Highness, and wherein it doth
consist, as whether in spiritual government or in temporal. If in spiritual, like as
the words of the Act do import, scilicet: Supreme Head of the Church of England
immediate and next under God, then it would be considered whether this House
hathe authority to grant them, and Her Highness to receive the same” (Strype,
Annals, I. i. 405).
[542] Calendar of Letters and State Papers relating to English Affairs, preserved
chiefly in the Archives of Simancas, 1558-80, pp. 37, 44, 50, 55, 66; Parker’s
Correspondence, p. 66; Zurich Letters, i. 33.
[543] The Act is printed in Gee and Hardy, Documents, etc. p. 442.
[544] The Acts of Henry VIII. which were revived were:—24 Hen. VIII. c. 12—The
Restraint of Appeals, passed in 1533; 23 Hen. VIII. c. 20—The conditional
Restraint of Annates; 25 Hen. VIII. c. 19—The Submission of the Clergy and
Restraint of Appeals of 1534; 25 Hen. VIII. c. 20—The Ecclesiastical Appointments
Act; The absolute Restraint of Annates, Election of Bishops, and Letters Missive Act
of 1534; 25 Hen. VIII. c. 21—Act forbidding Papal Dispensations and the Payment
of Peter’s Pence of 1534; 26 Hen. VIII. c. 14—Suffragan Bishops’ Act of 1534; and
28 Hen. VIII. c. 16—Act for the Release of such as have obtained pretended
Dispensations from the See of Rome. These Acts are all, save the last mentioned,
printed in Gee and Hardy, Documents, etc. pp. 178-232, 253-56.
[545] Ibid. p. 445.
[546] Ibid. p. 447.
[547] Ibid. p. 446.
[548] Ibid. p. 455.
[549] The Act is printed in Gee and Hardy, Documents, etc. pp. 458 ff.
[550] Gee and Hardy, Documents, etc. p. 371.
[551] The Device is printed in Strype, Annals, etc. I. ii. 392, and in Gee’s
Elizabethan Prayer Book and Ornaments (London, 1902), p. 195.
[552] Gee’s Elizabethan Prayer-Book and Ornaments, pp. 76 f.
[553] Zurich Letters, ii. 17.
[554] The Journal of the House of Commons, i. 54: “The Bill for the Order of
Service and Ministers in the Church” (Feb. 15th); The Book of Common Prayer and
Ministration of Sacraments (Feb. 16th).
[555] Calendar of State Papers, Venetian, 1558-80, p. 45: “a book passed by the
Commons”; cf. above, p. 392; cf. also Bishop Scot’s speech on the reading of the](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-61-2048.jpg)
![Bill which was emasculated by the Lords, in Strype’s Annals, I. ii. 408.
[556] Dr. Gee rejects the idea that Guest’s letter had anything to do with the Book
passed by the Commons and rejected by the Lords; cf. his Elizabethan Prayer-Book
and Ornaments, pp. 32 ff.; and for a criticism of Dr. Gee, Tomlinson, The
Elizabethan Prayer-Book and Ornaments; a Review, p. 12. Guest’s letter is printed
by Dr. Gee in his Elizabethan Prayer-Book, etc. p. 152, and more accurately by Mr.
Tomlinson in his tract, Why was the First Prayer-Book of Edward VI. rejected?
[557] “Il Schifanoya” reports the wrath of the Commons: They “grew angry, and
would consent to nothing, but are in very great controversy” (Calendar of State
Papers, Venetian, 1558-80, p. 52); cf. p. 392.
[558] Journal of the House of Commons, i. 57.
[559] Professor Maitland (English Historical Review, July 1903, p. 527 n.) and
Father J. H. Pollen (Dublin Review, January 1903) think that this proclamation of
the 22nd of March was never issued; but “Il Schifanoya” can hardly refer to any
other.
[560] “On Easter Day, Her Majesty appeared in the chapel, where Mass was sung
in English, according to the use of her brother, King Edward, and the communion
was received in both ‘kinds,’ kneeling, facendoli il sacerdote la credenza del corpo
et sangue prima; nor did he wear anything but the mere surplice (la semplice
cotta), having divested himself of the vestments (li paramenti) in which he had
sung Mass; and thus Her Majesty was followed by many Lords both of the Council
and others. Since that day things have returned to their former state, though
unless the Almighty stretch forth His arm a relapse is expected. These accursed
preachers, who have come from Germany, do not fail to preach in their own
fashion, both in public and in private, in such wise that they persuaded certain
rogues to forcibly enter the church of St. Mary-le-Bow, in the middle of Cheapside,
and force the shrine of the most Holy Sacrament, breaking the tabernacle, and
throwing the most precious consecrated body of Jesus Christ to the ground. They
also destroyed the altar and the images, with the pall (palio) and church linen
(tovalie), breaking everything into a thousand pieces. This happened this very
night, which is the third after Easter.... Many persons have taken the communion
in the usual manner, and things continue as usual in the churches” (Calendar of
State Papers, Venetian, 1558-80, p. 57).
[561] The speeches of Abbot Feckenham and Bishop Scot, reprinted in Gee’s
Elizabethan Prayer-Book, etc. pp. 228 ff., represent the arguments used in the
Lords. Scot’s speech was delivered on the third reading of the Act of Uniformity,
quite a month after the Westminster conference, and Feckenham’s may have been
made at the same time; still they show the arguments of the Romanists.
[562] Calendar of Letters and State Papers relating to English Affairs, preserved
principally in the Archives of Simancas, 1558-67, pp. 45, 46-48; Zurich Letters, i.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-62-2048.jpg)
![13ff.; Strype’s Annals, etc. I. i. 128-40, I. ii. 466; Calendar of State Papers,
Venetian, 1558-80, pp. 64, 65.
[563] “King Edward’s reformation satisfieth the godly”: Bullinger to Utenhovius
(Zurich Letters, 2nd series, p. 17 n.; Strype, Annals, I. i. 259).
[564] May 20th, Cox to Weidner: “The sincere religion of Christ is therefore
established among us in all parts of the kingdom, just in the same manner as it
was formerly promulgated under our Edward of blessed memory” (Zurich Letters,
i. 28).
May 21st, Parkhurst to Bullinger: “The Book of Common Prayer, set forth in the
time of King Edward, is now again in general use throughout England, and will be
everywhere, in spite of the struggles and opposition of the pseudo-bishops”
(Zurich Letters, i. 29).
May 22nd, Jewel to Bullinger: “Religion is again placed on the same footing on
which it stood in King Edward’s time; to which event I doubt not but that your own
letters and those of your republic have powerfully contributed” (Zurich Letters, i.
33).
May 23rd, Grindal to Conrad Hubert: “But now at last, by the blessing of God,
during the prorogation of Parliament, there has been published a proclamation to
banish the Pope and his jurisdiction altogether, and to restore religion to that form
which we had in the time of Edward VI.” (Zurich Letters, ii. 19).
Dr. Gee seems to beg an important historical question when he says that these
letters must have been written before the writers knew that the Prayer-Book had
been actually altered in more than the three points mentioned in the Act of
Uniformity. Grindal, writing again to Hubert on July 14th, when he must have
known everything, says: “The state of our Church (to come to that subject) is
pretty much the same as when I last wrote to you, except only that what had
heretofore been settled by proclamations and laws with respect to the reformation
of the churches is now daily being carried into effect.” Cf. Gee’s Elizabethan
Prayer-Book, etc. p. 104 n., for the actual differences between the Edwardine
Book of 1552 and the Elizabethan Book of 1559.
[565] Cambridge Modern History, ii, 570.
[566] The rubric explaining kneeling at the communion had not the authority of
Parliament, but only of the Privy Council, and was not included.
The rubric of 1552 regarding ornaments, which had the authority of Parliament
and was re-enacted by the Act of Uniformity of 1559, was: “And here is to be
noted that the minister at the time of communion, and at all other times in his
ministration, shall use neither alb, vestment, nor cope; but being archbishop or
bishop, he shall have and wear a rochet: and being priest or deacon, he shall have
and wear a surplice only.”](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-63-2048.jpg)
![This is the real ornaments rubric of the Elizabethan settlement, and appears to be
such in the use and wont of the Church of England from 1559 to 1566, save that
copes were used occasionally.
The proviso in the Act of Uniformity (1559) was: “Such ornaments of the Church
and of the ministers thereof shall be retained and be in use as was in this Church
of England by authority of Parliament in the second year of the reign of King
Edward VI., until other order shall be therein taken by the authority of the Queen’s
Majesty, with the advice of her commissioners appointed and authorised under the
Great Seal of England for causes ecclesiastical, or of the metropolitan of this
realm.”
The ornaments in use in the second year of Edward VI. are stated in the rubrics of
the first Prayer-Book of King Edward (1549):
“Upon the day, and at the time appointed for the ministration of the Holy
Communion, the Priest that shall execute the holy ministry shall put upon him the
vesture appointed for that ministration, that is to say: a white Albe plain, with a
vestment or Cope. And where there be many Priests or Deacons, there so many
shall be ready to help the Priest in the ministration as shall be requisite: and shall
have upon them likewise the vestures appointed for their ministry, that is to say,
Albes with tunicles.” At the end there is another rubric: “Upon Wednesdays and
Fridays, the English Litany shall be said or sung in all places after such form as is
appointed by the King’s Majesty’s Injunctions; or as is or shall be otherwise
appointed by His Highness. And though there be none to communicate with the
Priest, yet these days (after the Litany ended) the Priest shall put upon him a plain
Albe or surplice, with a cope, and say all things at the Altar appointed to be said at
the celebration of the Lord’s Supper, until after the offertory.”
[567] Parker’s Correspondence, p. 65.
[568] The rubric is: “And here it is to be noted that the minister at the time of
communion and at all other times in his ministrations, shall use such ornaments in
the church as were in use by authority of Parliament in the second year of the
reign of King Edward VI., according to the Act of Parliament set in the beginning
of this Book.”](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-64-2048.jpg)
![[569] Dr. Gee (Elizabethan Ornaments, etc. p. 131) thinks that there can be no
reasonable doubt that the rubric was recorded on the authority of the Privy
Council. “The Privy Council had certainly inserted the Black Rubric in 1552, as their
published Acts attest, but all the records of the Privy Council from 13th May 1559
until 28th May 1562 have disappeared.” The precedent cited is scarcely a parallel
case. The Black Rubric was an explanation; the Rubric of 1559 is almost a
contradiction in terms of the Act which restores the Prayer-Book of 1552. If I may
venture to express an opinion, it seems to me most likely that the rubric was
added by the Queen herself, and that she inserted it in order to be able to
“hedge.” It is too often forgotten that the danger which overshadowed the earlier
years of Elizabeth was the issue of a papal Bull proclaiming her a heretic and a
bastard, and inviting Henry II. of France to undertake its execution. The Emperor
would never permit such a Bull if Elizabeth could show reasonable pretext that she
and her kingdom held by the Lutheran type of Protestantism. An excommunication
pronounced in such a case would have invalidated his own position, which he
owed to the votes of Lutheran Electors. In the middle of the sixteenth century the
difference between the different sections of Christianity was always estimated in
the popular mind by differences in public worship, and especially in the celebration
of the Lord’s Supper. All over Germany the Protestant was distinguished from the
Romanist by the fact that he partook of the communion in both “kinds.” Elizabeth
had definitely ranged herself on the Protestant side from Easter Day 1559; and a
more or less ornate ritual could never explain away the significance of this fact.
The great difference between the Lutherans and the Calvinists to the popular mind
was that the former retained and the latter discarded most of the old ceremonial.
Luther says expressly: “Da lassen wyr die Messgewand, altar, liechter noch
bleyben” (Daniel, Codex Liturgicus Ecclesiæ, Lutheranæ, p. 105); and crosses,
vestments, lights, and an altar appear in regular Lutheran fashion whenever the
Queen wished to place herself and her land under the shield of the Augsburg
Peace. This rubric was a remarkably good card to play in the diplomatic game.
[570] XXXth Injunction of 1559: “Item, Her Majesty being desirous to have the
prelacy and clergy of this realm to be had as well in outward reverence, as
otherwise regarded for the worthiness of their ministries, and thinking it necessary
to have them known to the people in all places and assemblies, both in the church
and without, and thereby to receive the honour and estimation due to the special
messengers and ministers of Almighty God, wills and commands that all
archbishops and bishops, and all other that be called or admitted to preaching or
ministry of the sacraments, or that be admitted into any vocation ecclesiastical, or
into any society of learning in either of the Universities or elsewhere, shall use and
wear such seemly habits, garments, and such square caps as were most
commonly and orderly received in the latter year of the reign of King Edward VI.;
not meaning thereby to attribute any holiness or special worthiness to the said
garments, but as St. Paul writeth: ‘Omnia decenter et secundum ordinem fiant’ (1](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-65-2048.jpg)
![Cor. xiv. cap.).” Cf. Gee’s Elizabethan Prayer Booke and Ornaments (London,
1902); Tomlinson, The Prayer Book, Articles and Homilies (London, 1897); Parker,
The Ornaments Rubric (Oxford, 1881).
[571] The Advertisements are printed in Gee and Hardy; Documents, etc. p. 467;
the Injunctions, at p. 417.
[572] Copes were used in the cathedrals and sometimes in collegiate churches in
the years between 1559 and 1566, when it was desired to add some magnificence
to the service; but it ought to be remembered that the cope was never a sacrificial
vestment. It was originally the cappa of the earlier Middle Ages—the mediæval
greatcoat. Large churches were cold places, the clergy naturally wore their
greatcoats when officiating, and the homely garment grew in magnificence. It
never had a doctrinal significance like the chasuble or casula.
[573] Calendar of State Papers, Spanish, 1558-67, p. 89.
[574] Machyn’s Diary (Camden Society, London, 1844), p. 108.
[575] Peacock’s Church Furniture, p. 87.
[576] Calendar of State Papers, Spanish, 1558-67, p. 105: “The crucifixes and
vestments that were burnt a month ago publicly are now set up again in the royal
chapel, as they soon will be all over the kingdom, unless, which God forbid, there
is another change next week. They are doing it out of sheer fear to pacify the
Catholics; but as forced favours are no sign of affection, they often do more harm
than good.” Cf. Zurich Letters, i. 63, etc.
[577] Calendar of Letters and State Papers relating to English Affairs, preserved
principally in the Archives of Simancas, i. pp. 76, 79.
[578] Calendar of State Papers, Domestic Series, Edward VI., Mary, Elizabeth, i.
130.
[579] The Injunctions are printed in Gee and Hardy, Documents, etc. p. 417.
[580] Calendar of State Papers, Domestic Series, of the Reigns of Edward VI.,
Mary, and Elizabeth, i. pp. 180, 183, 187.
[581] For the history of these Articles, see Hardwick, A History of the Articles of
Religion; to which is added a Series of Documents from A.D. 1536 to A.D. 1615,
etc. (Cambridge, 1859).
[582] Calendar of Letters and State Papers relating to English Affairs, preserved
principally in the Archives of Simancas, i. 190.
[583] The Consensus Tigurinus (1549) dates the disappearance.
[584] The Zurich Letters, 1558-79, First Series (Parker Society, Cambridge, 1842),
pp. 123, 127, 135, 100, 139. Bishop Jewel, writing to Peter Martyr (p. 100), says:
“As to matters of doctrine, we have pared everything away to the very quick, and](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-66-2048.jpg)
![do not differ from your doctrine by a nail’s breadth” (Feb. 7th, 1562); and Bishop
Horn, writing to Bullinger (Dec. 13th, 1563, i.e. after the Queen’s alterations),
says,: “We have throughout England the same ecclesiastical doctrine as
yourselves” (ibid. p. 135).
[585] The deleted clause was: “Christus in cœlum ascendens, corpori suo
immortalitatem dedit, naturam non abstulit, humanæ enim naturæ veritatem
(juxta Scripturas), perpetuo retinet, quam uno et definito loco esse, et non in
multa, vel omnia simul loca diffundi oportet. Quum igitur Christus in cœlum
sublatus, ibi usque ad finem seculi permansurus, atque inde, non aliunde (ut
loquitur Augustinus) venturus sit, ad judicandum vivos et mortos, non debet
quisquam fidelium, et carnis eius, et sanguinis, realem et corporealem (ut
loquuntur) presentiam in Eucharistia vel credere, vel profiteri.”
[586] “Cette reine est extremement sage, et a des yeux terribles.” Calendar of
State Papers, Domestic Series, of the Reign of Elizabeth, 1595-97, p. xxi.
[587] Calendar of Letters and State Papers relating to English Affairs, preserved
principally in the Archives of Simancas, i. 61, 62.
[588] Calendar of State Papers, Venetian, 1558-80, p. 449.
[589] The Zurich Letters, etc., First Series, p. 91.
[590] The Zurich Letters, etc., First Series, p. 74; cf. 55, 63, 64, 66, 68, 100, 129,
135. Bishop Jewel called clerical dress the “relics of the Amorites” (p. 52), and
wished that he could get rid of the surplice (p. 100); and “the little silver cross” in
the Queen’s chapel was to him an ill-omened thing (p. 55); cf. Strype, Annals, etc.
I. i. 260.
[591] Annals, etc. I. ii. 562.
[592] The Advertisements of Archbishop Parker, issued and enforced on the
authority of the Primate, to which the royal imprimatur was more than once
refused, may be looked on as an exception. For these rules, meant to control the
Church in the vestiarian controversy, see Gee and Hardy, Documents, etc. p. 467;
and for the vexed question of their authority, Moore, History of the Reformation, p.
266.
[593] Maitland, Cambridge Modern History, ii. 569 ff.
[594] Calendar of State Papers, Domestic Series, of the Reigns of Edward VI.,
Mary, and Elizabeth, 1547-80, p. 159.
[595] Calendar of State Papers, Domestic Series, etc. p. 247.
[596] Ibid. p. 177; Calendar of Letters and State Papers relating to English Affairs,
preserved principally in the Archives of Simancas, i. 77, 118, 119.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-67-2048.jpg)
![[597] The story of Francis Yaxley, Mary’s agent, of his dealings with Philip II., of
Philip’s subsidy to Scotland of 20,000 crowns, of its loss by shipwreck, and how
the money was claimed as treasure-trove by the Duke of Northumberland, Roman
Catholic and a pledged supporter of Mary as he was, may be traced in the
Calendar of Letters and State Papers relating to English Affairs, preserved
principally in the Archives of Simancas, pp. lix, 499, 506, 516, 523, 546, 557; and
how the Pope also gave aid in money, p. 559.
[598] For example, the Nikolsburger Articles say: “Cristus sei in der erbsunden
entphangen; Cristus sei nit Got sunder ein prophet, dem das gesprech oder wort
Gottes bevollen worden” (Cornelius, Geschichte des Münsterischen Aufruhrs, ii.
279, 280).
[599] Servede was born in 1511, in the small town of Tudela, which then belonged
to Aragon. He came from an ancient family of jurists, and was at first destined to
the profession of law. His family came originally from the township of Villanova,
which probably accounts for the fact that Servede sometimes assumed that name.
He was in correspondence with Oecolampadius (Heusgen) in 1530; and from the
former’s letters to and about Servede, it is evident that the young Spaniard was
then fully persuaded about his anti-Trinitarian opinions. No publisher in Basel
would print his book, and he travelled to Strassburg. When his first theological
book became known, its sale was generally interdicted by the secular authorities.
His great book, which contains his whole theological thinking, was published in
1553 without name of place or author. Its full title is: Christianismi Restitutio,
Totius ecclesiæ apostolicæ ad sua limina vocatio, in integrum restituta cognitione
Dei, fidei Christi, justificationis nostræ, regenerationis baptisimi et cœnæ domini
manducationis, Restituto denique nobis regno cœlesti, Babylonis impiæ captivitate
soluta, et Antichristo cum suis penitus destructo. He entered into correspondence
with Calvin, offered to come to Geneva to explain his position; but the Reformer
plainly indicated that he had no time to bestow upon him. The account of his trial,
condemnation, and burning at Geneva is to be found in the Corpus Reformatorum,
xxxvi. 720 ff. The sentence is found on p. 825: “Icy est este parle du proces de
Michiel Servet prisonnier et veu le sommairre dycelluy, le raport de ceux esquelz
lon a consulte et considere les grands erreurs et blaffemes—est este arreste Il soit
condampne a estre mene en Champel et la estre brusle tout vyfz et soit exequente
a demain et ses livres brusles.” This trial and execution is the one black blot on the
character of Calvin. He was by no means omnipotent in Geneva at the time; but
he thoroughly approved of what was done, and had expressed the opinion that if
Servede came to Geneva, he would not leave it alive. “Nam si venerit modo valeat
mea auctoritas, virum exire nunquam patiar” (Corpus Ref. xi. 283).
[600] Ritschl, A critical History of the Christian Doctrine of Justification and
Reconciliation (Eng. trans., Edin. 1872), p. 295.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-68-2048.jpg)
![[601] “Circa annum 1546 instituerat (Lælius Socinus) cum sociis suis iisdem Italis,
quorum numerus quadragenarium excedebat, in Veneta ditione (apud Vincentiam)
collegia colloquiaque de religione, in quibus potissimum dogmata vulgaria de
Trinitate ac Christi Satisfactione hisque similia in dubium revocabant” (Bibl. Antit.
p. 19—I have taken the quotation from Fock, Der Socinianismus nach seiner
Stellung in der Gesammtentwickelung des christlichen Geistes, etc., Kiel, 1847, i.
132).
[602] Sources: Magna Bibliotheca Veterum Patrum (Coloniæ Agrippinæ, 1618), xiii.
299-307; Sebastian Franck, Chronica, Zeitbuch und Geschichtbibel (Augsburg,
1565), pt. iii.; Hans Denck, Von der waren Lieb, etc. (1527—republished by the
Menonitische Verlagsbuchhandlung, Elkhart, Indiana, U.S.A.); Bouterwek, Zur
Literatur und Geschichte der Wiedertäufer (Bonn, 1864—gives extracts from the
rarer Anabaptist writings such as the works of Hübmaier); Ausbund etlicher
schöner christlicher geseng, etc. (1583); Liliencron, “Zur Liederdichtung der
Wiedertäufer” (in the Abhandlungen der könig. Bair. Akad. der Wissenschaften
Philosophische Klasse, 1878); von Zezschwitz, Die Katechismen der Waldenser und
Bömischen Bruder (Erlangen, 1863); Beck, Geschichts-Bücher der Wiedertäufer in
Österreich-Ungarn, 1526 bis 1785 (Vienna, 1883), printed in the Fontes Rer. Austr.
Diplom. et Acta, xliii.; Kessler, Sabbata, ed. by Egli and Schoch (St. Gall, 1902);
Bullinger, Der Wiedertäuferen Ursprung, Secten, etc. (Zurich, 1560); Egli,
Actensammlung zur Geschichte der Züricher Reformation (Zurich, 1879), Die
Züricher Wiedertäufer (Zurich, 1878); Leopold Dickius, Adversus impios
Anabaptistarum errores (1533); Cornelius, Berichte der Augenzeugen über das
Münsterische Wiedertäuferreich, forming the 2nd vol. of the Geschichtsquellen des
Bisthums Münster (Münster, 1853) and the Beilage in his Geschichte des
Münsterischen Aufruhrs (Leipzig, 1855); Detmer’s edition of Kerssenbroch,
Anabaptistici furoris Monasterium inclitam Westphaliæ metropolim evertentis
historica, narratio, forming vols. v. and vi. of the Geschichtsquellen des Bisthums
Münster (Münster, 1899, 1900); Chroniken der deutschen Städte, Nürnberg
Chronik, vols. i. and iv.
Later Books: Keller, Geschichte der Wiedertäufer und ihres Reichs zu Münster
(Münster, 1880), Ein Apostel der Wiedertäufer; Hans Denck (Leipzig, 1882), and
Die Reformation und die älteren Reformparteien (Leipzig, 1885—Keller is apt to
make inferences beyond his facts); Heath, Anabaptism, from its rise at Zwickau to
its fall at Münster, 1521-1536 (London, 1895); Belfort Bax, Rise and Fall of the
Anabaptists (London, 1903); Rörich, “Die Gottesfreunde und die Winkeler am
Oberrhein” (in Zeitschrift für hist. Theol. i. 118 ff., 1840); Zur Geschichte der
strassburgischen Wiedertäufer (Zeitschrift für hist. Theol. xxx. 1860); S. B. ten
Cate, Geschiedenis der doopgezinden in Groningen, etc., 2 vols. (Leeuwarden,
1843); Geschiedenis der doopgezinden in Friesland (Leeuwarden, 1839);
Geschiedenis der doopgezinden in Holland en Guelderland, 2 vols. (Amsterdam,
1847); Tileman van Braght, Het bloedig Toenecl of Martclaars Spiegel der](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-69-2048.jpg)
![doopgesinde (Amsterdam, 1685); E. B. Underhill, Martyrology of the Churches of
Christ commonly called Baptist (translated from Van Braght); H. S. Burrage, A
History of the Anabaptists in Switzerland (founded on Egli’s researches,
Philadelphia, 1881); Newman, A History of Anti-Pedobaptism (Philadelphia, 1897);
Detmer, Bilder aus den religiösen und sozialen Unruhen in Münster während des
16 Jahrhunderts: i. Johann von Leiden (Münster, 1903), ii. Bernhard Rothmann
(1904), iii. Ueber die Auffassung von der Ehe und die Durchführung der
Vielweiberei in Münster während der Täuferherrschaft (1904); Heath,
Contemporary Review, lix. 389 (“The Anabaptists and their English Descendants”),
lxii. 880 (“Hans Denck the Baptist”), lxvii. 578 (Early Anabaptism, what it meant,
and what we owe to it), lxx. 247 (“Living in Community—a sketch of Moravian
Anabaptism”), 541 (“The Archetype of the Pilgrim’s Progress”), lxxii. 105 (“The
Archetype of the Holy War”).
[603] The difference in treatment may be seen at a glance by comparing the
articles on Anabaptism in the second (1877) and in the third (1896) edition of
Herzog’s Realencyclopädie für protestantische Theologie und Kirche. Some
eminent historians, however, still cling to old ideas; for example, Edward
Armstrong, The Emperor Charles V. (London, 1902), who justifies the treatment
his hero meted out to the Anabaptists—roasting them to death before slow fires—
by saying that “whenever they momentarily gained the upper hand, they applied
the practical methods of modern Anarchism or Nihilism to the professed principles
of Communism” (ii. 342). No one who has examined the original sources could
have penned such a sentence.
[604] Magna Bibliotheca Veterum Patrum (Coloniæ Agrippinæ, 1618), xiii. 299,
300, 307 (the Summa of Raiverus Sacchonus). Cf. i. 152.
[605] These are the dates at which town chronicles incidentally show that such
communities existed, not the dates of their origin.
[606] Vedder, Balthasar Hübmaier (New York, 1905).
[607] Liliencron, “Zur Liederdichtung der Wiedertäufer,” in the Transactions of the
Königl. Bair. Akad. der Wissenschaften, Philosophisch-historische Klasse, 1877.
[608] Chronica (Augsburg edition, 1565), f. 164.
[609] Der Wiedertäuferen Ursprung, Furgang, Secien, etc. (Zurich, 1560).
[610] Chronica (3 pts., Strassburg, 1531).
[611] Sabbata (ed. by Egli and Schoch, St. Gall, 1902).
[612] C. A. Cornelius, Geschichte des Münsterischen Aufruhrs (Leipzig, 1855), ii.
49.
[613] Ibid. ii. 49.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-70-2048.jpg)
![[614] Magna Bibliotheca Veterum Patrum (Coloniæ Agrippinæ, 1618), Rainerii
Socchoni, Summa, c. vii.
[615] Egli, Die Züricher Wiedertäufer (Zurich, 1878), p. 96.
[616] Folio 158b of the Augsburg edition of 1565.
[617] The Swiss Anabaptists have been selected because we have very full
contemporary documentary evidence in their case. Cf. Egli, Actensammlung zur
Geschicht der Züricher Reformation (Zurich, 1879); Die Zuricher Wiedertäufer
(Zurich, 1878); Die St. Gallen Wiedertäufer (Zurich).
The documentary evidence given in Egli’s works has been condensed and
summarised by H. S. Burrage, A History of the Anabaptists in Switzerland
(Philadelphia, 1881).
[618] The scene is described in Beck, Die Geschichts-Bücher der Wiedertäufer in
Österreich-Ungarn von 1526 bis 1785 (Vienna, 1883).
[619] The history of the persecution in the Tyrol is to be found in J. Loserth,
Anabaptismus in Tirol; and in Kirchmayr, Denkwürdigkeiten seiner Zeit, 1519-53,
pt. i. in Fontes Rerum Austriacarum, i. 417-534.
[620] Cornelius, Geschichte des Münsterischen Aufruhrs (Leipzig, 1855), ii. 58.
[621] The disease was known as the English plague or the sweating sickness. It is
thus described by Hecker (Epidemics of the Middle Ages, p. 181): “It was violent
inflammatory fever, which, after a short rigour, prostrated the powers as with a
blow; and amidst painful oppression at the stomach, headache, and lethargic
stupor, suffused the whole body with fœtid perspiration. All this took place within
the course of a few hours, and the crisis was always over within the space of a
day and a night. The internal heat that the patient suffered was intolerable, yet
every refrigerant was death.”
[622] Rothmann was born at Stadtlohn, and received the rudiments of education
in the village school there; a relation sent him to the Gymnasium at Münster; he
studied afterwards at Mainz, where he received the degree of M.A.; he was made
chaplain in the St. Maurice church at Münster about 1525.
[623] His confession of faith, published in Latin and German in 1532, shows this. I
know it only by the summary in Detmer (Bernhard Rothmann, Münster, 1904, pp.
41 f.). Detmer says that he knows of only one printed copy, which is in the
University Library at Münster.
[624] Bernardin Knipperdolling or Knipperdollinck (both forms are found) was a
wealthy cloth merchant, an able and fervent speaker, a man of strong convictions,
who had early espoused the people’s cause, and had become the trusted leader of
the democracy of Münster.](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-71-2048.jpg)
![[625] The details of this Disputation have been published by Detmer in the
Monatshefte der Commenius-Gesellschaft (Berlin, 1900), ix. 273 ff.
[626] Cf., above, ii. 235 ff.
[627] Meister Heinrich Gresbeck’s Bericht von der Wiedertaufe in Münster, p. 20
(edited by Cornelius for Die Geschichtsquellen des Bisthums Münster, vol. ii.,
Münster, 1853).
[628] Cf. Die Münsterische Apologie, printed by Cornelius in his Berichte der
Augenzeugen über das münsterische Wiedertäuferreich, p. 457 (Geschichtsquellen
des Bisthums Münster, vol. ii.).
[629] By far the best and most impartial discussion of the institution of polygamy
in Münster—one that is based on the very widest examination of contemporary
documentary evidence—is that of Dr. Detmer, Ueber die Auffassung von der Ehe
und die Durchführung der Vielweiberei in Münster während der Täuferherrschaft
(Münster, 1904). It forms the third of his Bilder aus den religiösen und sozialen
Unruhen in Münster während des 16. Jahrhunderts.
[630] The tract is to be found in Cornelius, Berichte der Augenzeugen über das
münsterische Wiedertäuferreich, which forms the second volume of Die
Geschichtsquellen des Bisthums Münster (pp. 445 ff.).
[631] “Die ehe, sagen wir und halten mit der Schrift, das sie ist eins mans und
weips vorgaderong und vorpflichtong in dem Herrn ... Got hot den menchen von
anfanck geschaffen, ein man und weip hat Er sie geschaffen, di peide in den
heiligen estant (ehestat) voreiniget, dos di peide zwo sellen und ein fleische solen
sein. Und mage also kein mensche scheiden selche voreinigong” (pp. 457, 458).
[632] The Restitution, written by Rothmann and Kloprys in conjunction with Jan of
Leyden and the elders, is published in Bouterwek, Literatur und Geschichte der
Wiedertäufer; marriage and polygamy are treated in sections 14-16.
[633] Jan Bockelson, commonly called Jan van Leyden, was the illegitimate son of
a village magistrate, and was born near Leyden in 1510. After a brief time of
education at a village school he was apprenticed to a tailor, and in his leisure
hours diligently educated himself. He travelled more widely than artisans usually
did during their year of wandering—visiting England as well as most parts of
Flanders. On his return home he married the widow of a shipmaster, and started
business as a merchant. He was a prominent member of the literary “gilds” of his
town, and had a local fame as a poet and an actor. His conversion through Jan
Matthys changed his whole life; there is not the slightest reason to suppose that
he was not an earnest and honest adherent of the Anabaptist doctrines as taught
by Matthys. He is described as strikingly handsome, with a fine sonorous voice. He
had remarkable powers of organisation. His whole brief life reveals him to be a](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-72-2048.jpg)
![very remarkable man. He was barely twenty-five when he was tortured to death
by the Bishop of Münster after the capture of the town.
[634] Sources: Bibliotheca Fratrum Polonorum (Amsterdam, 1656) i. ii. Racovian
Catechism (London, 1818).
Later Books: Fock, Der Socinianismus nach seiner Stellung in der
Gesammtentwickelung des christlichen Geistes, nach seinem historischen Verlauf
und nach seinem Lehrbegriff dargestellt (Kiel, 1847); A. Ritschl, Jahrbücher f.
deutsche Theologie, xiii. 268 ff., 283 ff.; A critical History of the Christian Doctrine
of Justification and Reconciliation (Edinburgh, 1872); Dilthey, Archiv f. Geschichte
d. Philos. vi.; Harnack, History of Dogma, vii. 118 ff. (London, 1899).
[635] Pp. 397 ff.
[636] Cf. i. 426 ff.
[637] Harnack, History of Dogma, vii. 167.
[638] Cf. p. 427.
[639] Cf. i. 461.
[640] Erasmus, Opera Omnia, iv. 465.
[641] A very full analysis of the contents of the Racovian Catechism is given in
Harnack’s History of Dogma, vii. 137 ff., also in Fock, Der Socinianismus, etc. ii. A.
Ritschl has shown that the Unitarianism of the Socinians is simply the legitimate
conclusion from their theory of the nature of God and of the work of Christ, in his
two essays in the Jahrbücher f. deutsche Theol. xiii, 268 ff., 283 ff.
[642] Sources: Laemmer, Monumenta Vaticana historiam ecclesiasticam seculi 16
illustrantia (Freiburg i. B. 1861); Weiss, Papiers d’État du Cardinal Perronet de
Granvelle (in the Collection des documents inédits de l’Histoire de France, 1835-
49); Fiedler, Relationen Venetianischer Botschaften über Deutschland und
Oesterreich im 16ten Jahrhunderte (in the Fontes Rerum Austriacarum,
Diplomatica et Acta, xxx., Vienna, 1870); Friedenburg, Nuntiaturberichte aus
Deutschland, 1533-39 (Gotha, 1892-93); Carteggio di Vittoria Colonna (Rome,
1889).
Later Books: Maurenbrecher, Geschichte der katholischen Reformation (Nördlingen,
1880—only one volume published, which ends with 1534); also Karl V. und die
deutschen Protestanten (Düsseldorf, 1865); Ranke, Die römischen Päpste, ihre
Kirche und ihr Staat im sechszehnten und siebzehenten Jahrhundert; Gothein,
Ignatius von Loyola und die Gegenreformation (Halle, 1895); Philippson, La
Contre-Revolution religieuse du 16e siècle (Brussels, 1884); Ward, The Counter-
Reformation (London, 1889); Dupin, Histoire de l’Église du 16e siècle (Paris, 1701-
13); Jerrold, Vittoria Colonna (London, 1906).](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-73-2048.jpg)
![[643] Cf. A Relation ... of the Island of England ... about the year 1500 (Camden
Society, London, 1847), pp. 34-36, 86-89.
[644] Cf. i. 36.
[645] This had been protested against for a century and a half, not merely by
individual moralists, but by such conventions of notables as the English
Parliament; cf. Rolls of Parliament, ii. 313-14; Item, “prie la Communeque comme
autre foithz au Parlement tenuz a Wyncestre, supplie y fuist par la Commune de
remedie de ce que les Prelatz et Ordinares de Seint Esglise pristrent sommes
pecuniers de gentz de Seint Esglise et autres pur redemption de lour pecche de
jour en jour, et an en an, de ce que ils tiendrent overtement lours concubines; et
pur autres pecches et offenses a eux surmys, dount peyne pecunier ne serroit pris
de droit: Quele chose est cause, meintenance et norisement de lour pecche, en
overte desclandre, et mal ensample de tut la Commune; quele chose issint
continue nient duement puny, est desesploit an Roi et a tout le Roialme. Qe pleise
a nostre Seigneur le Roi ent ordeiner que touz tiels redemptions soient de tut
ousteiz; et que si nul viegne encontre ceste Ordeinance, que le prenour encourge
la somme del double issint pris devers la Roi et cely que le paie eit mesme la
peyne.”
[646] Cf. i. 166, 213.
[647] Cf. vol. i. 140, 141, 378; vol. ii.
[648] Letters and Papers, Foreign and Domestic, of the Reign of Henry VIII., iv.,
Preface, p. 485. Cf. Brown, Fasciculus rerum expectendarum et fugiendarum
(1690), pp. 19, 20, for the speech of an English Bishop at Rome (Nov. 27th,
1425), saying that if the Curia does not speedily undertake the work of
Reformation, the secular powers must interfere.
[649] Lea, Chapters from the Religious History of Spain (Philadelphia, 1890);
Prescott, Ferdinand and Isabella (London, 1887); V. de la Fuente, Historia
eclesiastica en Espana (Madrid, 1873, etc.); Menendezy Palayo, Los Heterodoxos
Espanoles (Madrid, 1880); Hefele, The Cardinal Ximenes (London, 1860); Paul
Rousselot, Les Mystiques Espagnols (Paris, 1867).
[650] Cf. paper read by Charles V. to the Estates of Germany at Worms—Wrede,
Deutsche Reichstagsakten unter Kaiser Karl V. (Gotha, 1896) ii. 595.
[651] “Is Cæsaris consanguineus, legatus missus a Wormacia, festinando ad
Hispanos pro sedando quodam tumultu. Is in profesto vigiliæ natalicii dominici
superveniens eques, cum ministris, biduo manens integro et tribus noctibus, mihi
multum loquebatur de causa Lutherana, quæ magna ex parte arridebat viro bono
et docto, præter librum de captivitate Babel, quem legerat Wormatiæ cum mœrore
et displicentia, quem ego nondum videram.” Riggenbach, Das Chronikon des
Konrad Pellikan, p. 77 (Basel, 1877).](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-74-2048.jpg)
![[652] Carvajal’s speech and Egidio’s memoir are given in Höfler, “Analecten z.
Geschich. Deutschlands und Italiens” (Abhandlungen der Münch. Akad. IV. iii. 57-
89).
[653] An indult can be best explained by an example: according to the Council of
Bourges (1438), the selection of French Bishops was left exclusively in the hands
of the Chapters of the Cathedrals; but Pope Eugenius IV. permitted Charles VII.
the right to appoint to several specified bishoprics; such a papal grant was called
an indult.
[654] Cf. vol. i. 12 f.
[655] Sources: Contarini, Opera (Paris, 1571); Correspondenz Contarinis, ed. by L.
Pastor (1880); Cortese, Epistolarum familiarum liber (Venice, 1573); Ghiberti,
Opera (Verona, 1740); Sadoleto, Epistolarum libri sexdecim (Lyons, 1560); Pole,
Epistolæ, et aliorum ad ipsum (Brescia, 1744-57), Carteggio di Vittoria Colonna
(Turin, 1889); Vergerio, Briefwechsel (edited for the Bibliothek des literarischen
Vercius, Stuttgart, 1875).
Later Books: Jacob Burckhardt, The Civilisation of the Period of the Renaissance
(Eng. trans., London, 1892); Symonds, Renaissance in Italy. The Catholic Reaction
(London, 1886); Cantù, Gli Eretici d’Italia (Turin, 1865-67); Braun, Cardinal
Gasparo Contarini (1903); Dittrich, Gasparo Contarini (Braunsberg, 1883); Duruy,
Le Cardinal Carlo Caruffa (Paris, 1882); Gothein, Ignatius Loyola und die
Geyenreformation, pp. 77-207 (Halle, 1895); v. Reumont, Vittoria Colonna
(Freiburg i. B. 1881).
[656] Mediæval songs tell us that this hatred of the peasantry is much older than
the Renaissance:
“Si quis scire vult naturam,
Maledictam et obscuram
Rusticorum genituram
Infelicem et non puram
Denotent sequentia,” etc.
Carmina Medii Æri (Florence, 1883), p. 34; the song belongs to the thirteenth
century.
[657] Herminjard, Correspondance, etc. viii. 161.
[658] The name went beyond the original foundation. The Jesuits were sometimes
called Theatines both in Spain and in France.
[659] They are to be found in Bibliotheca Maxima Pontificia (Rome, 1790), pp. 178
ff. The contents of the second letter are condensed in the phrase which occurs
near the end: “in legibus voluntas non debet regula esse” (p. 183). The first letter
urges the Pope to make an end of the scandals caused by the sale of](https://image.slidesharecdn.com/2351309-250527031429-a62220d8/75/Agile-Testing-How-To-Succeed-In-An-Extreme-Testing-Environment-John-Watkins-75-2048.jpg)
Agile Testing How To Succeed In An Extreme Testing Environment John Watkins
- 1. Agile Testing HowTo Succeed In An Extreme Testing Environment John Watkins download https://ebookbell.com/product/agile-testing-how-to-succeed-in-an- extreme-testing-environment-john-watkins-4702618 Explore and download more ebooks at ebookbell.com
- 2. Here are somerecommended products that we believe you will be interested in. You can click the link to download. Agile Testing https://ebookbell.com/product/agile-testing-4699714 Agile Testing A Practical Guide For Testers And Agile Teams 1st Edition Lisa Crispin https://ebookbell.com/product/agile-testing-a-practical-guide-for- testers-and-agile-teams-1st-edition-lisa-crispin-2099840 Agile Testing The Agile Way To Quality 1st Edition Manfred Baumgartner https://ebookbell.com/product/agile-testing-the-agile-way-to- quality-1st-edition-manfred-baumgartner-43027758 Agile Testing Foundations An Istqb Foundation Level Agile Tester Guide Rex Black https://ebookbell.com/product/agile-testing-foundations-an-istqb- foundation-level-agile-tester-guide-rex-black-6702918
- 3. More Agile TestingLearning Journeys For The Whole Team 1st Edition Janet Gregory https://ebookbell.com/product/more-agile-testing-learning-journeys- for-the-whole-team-1st-edition-janet-gregory-7037746 Agile Automation And Unified Funtional Testing Gupta Rajeev https://ebookbell.com/product/agile-automation-and-unified-funtional- testing-gupta-rajeev-22046160 The Agile Software Tester Software Testing In The Agile World K C Martin https://ebookbell.com/product/the-agile-software-tester-software- testing-in-the-agile-world-k-c-martin-36521260 The Agile Software Tester Software Testing In The Agile World Revision 7 Martin https://ebookbell.com/product/the-agile-software-tester-software- testing-in-the-agile-world-revision-7-martin-36521258 Agile Modeling With Uml Code Generation Testing Refactoring 1st Edition Bernhard Rumpe https://ebookbell.com/product/agile-modeling-with-uml-code-generation- testing-refactoring-1st-edition-bernhard-rumpe-5871542
- 6. This page intentionallyleft blank
- 7. AGILE TESTING: HOWTO SUCCEED IN AN EXTREME TESTING ENVIRONMENT In an IT world in which there are differently sized projects, with different applications, differently skilled practitioners, and onsite, offsite, and offshore development teams, it is impossible for there to be a one-size-fits-all agile development and testing approach. This book provides practical guidance for professionals, practitioners, and researchers faced with creating and rolling out their own agile testing processes. In addition to descriptions of the prominent agile methods, the book provides twenty real-world case studies of practitioners using agile methods and draws upon their experiences to populate your own agile method; whether yours is a small, medium, large, offsite, or even offshore project, this book provides personalized guidance on the agile best practices from which to choose to create your own effective and efficient agile method. John Watkins has more than thirty years of experience in the field of software development, with some twenty-five years in the field of software testing. Dur- ing his career, John has been involved at all levels and phases of testing and has provided high-level test process consultancy, training, and mentoring to numerous blue chip companies. He is both a Chartered IT Professional and a Fellow of the British Computer Society, where he is an active member of the Specialist Group in Software Testing (SIGiST), previously serving on committees of the Intellect Testing Group (representing the U.K. technology industry) and the SmallTalk User Group. He is author of Testing IT: An Off-the-Shelf Software Testing Process (Cam- bridge University Press, 2001) and currently works for IBM’s software group.
- 9. AGILE TESTING How toSucceed in an Extreme Testing Environment JOHN WATKINS
- 10. CAMBRIDGE UNIVERSITY PRESS Cambridge,New York, Melbourne, Madrid, Cape Town, Singapore, São Paulo, Delhi, Dubai, Tokyo Cambridge University Press The Edinburgh Building, Cambridge CB2 8RU, UK First published in print format ISBN-13 978-0-521-19181-4 ISBN-13 978-0-521-72687-0 ISBN-13 978-0-511-59546-2 © John Watkins 2009 2009 Information on this title: www.cambridge.org/9780521191814 This publication is in copyright. Subject to statutory exception and to the provision of relevant collective licensing agreements, no reproduction of any part may take place without the written permission of Cambridge University Press. Cambridge University Press has no responsibility for the persistence or accuracy of urls for external or third-party internet websites referred to in this publication, and does not guarantee that any content on such websites is, or will remain, accurate or appropriate. Published in the United States of America by Cambridge University Press, New York www.cambridge.org Paperback eBook (EBL) Hardback
- 11. “To my Father,My Methodical Role-Model”
- 13. Contents Foreword by BobBartlett page xi Acknowledgments xiii 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Why Agile? 1 1.2 Suggestions on How to Read This Book 3 PART 1. REVIEW OF OLD-SCHOOL AND AGILE APPROACHES 2 Old-School Development and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Introduction 7 2.2 So, What Is Process? 7 2.3 Waterfall 8 2.4 Spiral 9 2.5 Iterative 10 2.6 Traditional Elements of Test Process 13 2.7 Summary 16 3 Agile Development and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1 Introduction 18 3.2 Rapid Application Development 19 3.3 Extreme Programming 20 3.4 The Dynamic Systems Development Method 21 3.5 Scrum 23 3.6 Other Agile Methods 24 3.7 Summary 27 vii
- 14. viii Contents PART 2.EVERYONE IS DIFFERENT: AGILE CASE STUDIES 4 From Waterfall to Evolutionary Development and Test . . . . . . . . . . . . . . . 31 Tom Gilb and Trond Johansen 5 How to Test a System That Is Never Finished . . . . . . . . . . . . . . . . . . . . . 37 Nick Sewell 6 Implementing an Agile Testing Approach . . . . . . . . . . . . . . . . . . . . . . . 44 Graham Thomas 7 Agile Testing in a Remote or Virtual Desktop Environment . . . . . . . . . . . . . 49 Michael G. Norman 8 Testing a Derivatives Trading System in an Uncooperative Environment . . . . . 53 Nick Denning 9 A Mixed Approach to System Development and Testing: Parallel Agile and Waterfall Approach Streams within a Single Project . . . . . . . . . . . . . . . . . 62 Geoff Thompson 10 Agile Migration and Testing of a Large-Scale Financial System . . . . . . . . . . 66 Howard Knowles 11 Agile Testing with Mock Objects: A CAST-Based Approach . . . . . . . . . . . . . 72 Colin Cassidy 12 Agile Testing – Learning from Your Own Mistakes . . . . . . . . . . . . . . . . . . 81 Martin Phillips 13 Agile: The Emperor’s New Test Plan? . . . . . . . . . . . . . . . . . . . . . . . . . 86 Stephen K. Allot 14 The Power of Continuous Integration Builds and Agile Development . . . . . . . 93 James Wilson 15 The Payoffs and Perils of Offshored Agile Projects . . . . . . . . . . . . . . . . . 103 Peter Kingston 16 The Basic Rules of Quality and Management Still Apply to Agile . . . . . . . . . 115 Richard Warden 17 Test-Infecting a Development Team . . . . . . . . . . . . . . . . . . . . . . . . . . 122 David Evans 18 Agile Success Through Test Automation: An eXtreme Approach . . . . . . . . . 132 Jon Tilt
- 15. ix Contents 19 Talking,Saying, and Listening: Communication in Agile Teams . . . . . . . . . 139 Isabel Evans 20 Very-Small-Scale Agile Development and Testing of a Wiki . . . . . . . . . . . . 151 Dass Chana 21 Agile Special Tactics: SOA Projects . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Greg Hodgkinson 22 The Agile Test-Driven Methodology Experiment . . . . . . . . . . . . . . . . . . 180 Lucjan Stapp and Joanna Nowakowska 23 When Is a Scrum Not a Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Dr Peter May PART 3. AGILE MY WAY: A PROPOSAL FOR YOUR OWN AGILE TEST PROCESS 24 Analysis of the Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 24.1 Introduction 193 24.2 Agile Development and Testing 194 24.3 Agile Process and Project Management 200 24.4 Agile Requirements Management 207 24.5 Agile Communication 210 24.6 Agile Meetings 212 24.7 Agile Automation 216 24.8 Summary 222 25 My Agile Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 25.1 Introduction 224 25.2 Foundation Agile Best Practices 225 25.3 Agile Best Practices for Small-Sized Projects 230 25.4 Agile Best Practices for Medium-Sized Projects 232 25.5 Agile Best Practices for Large-Sized Projects 238 25.6 Agile Best Practices for Offsite and Offshore Projects 248 25.7 Summary 250 26 The Roll-out and Adoption of My Agile Process . . . . . . . . . . . . . . . . . . . 251 26.1 Introduction 251 26.2 Roll-out and Adoption 252 26.3 Maintenance of Your Agile Process 255 26.4 Summary 256
- 16. x Contents Appendix A.The Principles of Rapid Application Development . . . . . . . . . . . 259 Appendix B. The Rules and Practices of Extreme Programming . . . . . . . . . . . 263 Appendix C. The Principles of the Dynamic Systems Development Method . . . . 270 Appendix D. The Practices of Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Appendix E. Agile Test Script Template . . . . . . . . . . . . . . . . . . . . . . . . . 284 Appendix F. Agile Test Result Record Form Template . . . . . . . . . . . . . . . . . 292 Appendix G. Agile Test Summary Report Template . . . . . . . . . . . . . . . . . . 300 Appendix H. My Agile Process Checklist . . . . . . . . . . . . . . . . . . . . . . . . . 305 References 309 Index 313
- 17. Foreword Bob Bartlett, CIO,SQS It is fascinating to see that so many members of our global software development and implementation community are at last agreeing violently on the principles behind agile. It is gratifying to see developers and testers working side-by-side aiming for the same goals and supporting each other. If you didn’t know what agile was but could see productive, disciplined, and self-organizing teams engaged in developing working software prioritized by business value, you would know that whatever they are doing must be right. Testers in particular have benefited from greater pride in their work as they are accepted as equal partners in the software development team. Agile development and testing is a thirty-year-old overnight success; in fact, most of the younger developers and testers who so enthusiastically promote this new way of developing software had almost certainly not been born when the likes of Barry Boehm and James Martin first began to develop the Rapid Application Development (RAD) method! Agile certainly seems to be being promoted as the latest silver bullet for all software development problems; the topic is included at pretty much any software event, user group, or standards group you attend, and much of the IT literature is full of agile references. For example, I recently hosted a conference on Software and Systems Quality and invited as a keynote speaker a senior development manager from IBM, who spoke of the corporate-wide initiative – spearheaded by the Chairman – to implement agile methods and processes groupwide. He reported (with good evidence) that product teams have adopted an agile development method in order to be responsive to customer needs and deliver software on time and to budget, with much higher quality – measured by incredibly low rates of postrelease faults. This is not to say that agile doesn’t have its detractors; many traditional IT development practitioners will tell you agile only works for small, simple, and well- bounded software development projects, where the customer and development team are co-located and staffed by experienced and capable practitioners. Why wouldn’t a project succeed under such circumstances? So what happens if the customer or some of the team are offsite (or even offshore)? What happens if the application is large, complex, and carries significant technological risk? What if you can’t afford xi
- 18. xii Foreword to staffyour development project with highly experienced, capable, motivated, and very expensive agile experts? These are certainly some of the major challenges that agile must meet if it is going to be widely accepted, adopted, and used successfully. But in an IT world where there is no universal one-size-fits-all software development process, how can agile be successfully applied to small, medium, large, and offsite/offshore projects? How can agile be used to address complex, difficult, or special-needs IT projects? How can IT practitioners of varying experience and ability adopt and use agile best practices effectively? There is certainly a risk that such a megatrend as agile becomes overhyped and overexploited commercially. However, the enthusiasm to share experiences and the availability of free and open tools and information is building the community belief and commitment. I have observed many times how intuitively people adopt the agile principles and practices – particularly testers, who embrace their new-found ability to contribute from the outset and “design in” quality on projects. The enthusiasm is contagious and the results of agile teams as seen in systems and software products show what can be produced when there is a dynamic and flexible approach to achieving well-understood goals relentlessly prioritized by business value. This book is the product of a number of people who felt confident and committed enough to document their experiences in the hopes that others would share their positive results and success. Each case study tells a different success story and at first you may feel overwhelmed with good ideas and ways to develop software. Just bringing these stories together makes for a worthy and valuable book. I am pleased to see that the whole story is told from many perspectives, not just the testing side. I have known John Watkins for about ten years now. During that time, I have seen and listened to him evangelize about testing and have supported events he has organized, such as the Rational Industry Testing Forum and the Rational Testing User Group – both of which I have spoken at. His passion for effective and professional testing has been constant, as has his commitment to the industry. John has spoken several times at Software Quality Systems (SQS) events that I have organized, as well as at numerous industry-wide events. John was an invited keynote and session speaker at the Scandinavian Ohjelmistotestaus testing confer- ences, and spoke at the Software Quality Assurance Management (SQAM) testing conference in Prague. He has also been active in the British Computer Society (BCS) (having made Fellow in 1997) and the Object Oriented (OO) and Specialist Group in Software Testing (SIGiST) special interest groups (where he has spoken many times, sat on testing discussion panels, chaired “birds of a feather” sessions, and so forth). He helped me tremendously in setting up and running the Intellect Testing Group, where I was grateful to have him on the management committee and to have his participation by writing and presenting on test process. John has done a tremendous job to elicit the contributions in this book, but he provides an even greater service by finding the common threads and practices and explaining why twenty-three different people shared in success. I am sure John feels proud that so many people can share in the creation of this book and the contribution to the “My Agile” process he describes.
- 19. Acknowledgments I would verymuch like to thank the following people for their advice, assistance, and encouragement in the writing of this book: Scott Ambler, Christine Mitchell-Brown, David Burgin, Dawn Davidsen, Abby Davies, Dorothy Graham, Andrew Griffiths, Dr Jon Hall, Karen Harrison, Elis- abeth Hendrickson, Ivar Jacobson, Anthony J Kesterton, Nick Luft, Frank Mal- one, Simon Mills, Simon Norrington, Jean-Paul Quenet, Andrew Roach, Manish Sharma, Jamie Smith, Ian Spence, Julie Watkins, and Nigel Williams. I would also like to thank the following people for their invaluable contribution in providing the agile case studies: Stephen K. Allott, Managing Director of ElectroMind Colin Cassidy, Software Architect for Prolifics Ltd Dass Chana, Computer Science Student Nick Denning, Chief Executive Officer of Diegesis David Evans, Director of Methodology at SQS Ltd Isabel Evans, Principal Consultant at the Testing Solutions Group Ltd Tom Gilb, independent testing practitioner and author Greg Hodgkinson, Process Practice Manager, Prolifics Ltd Trond Johansen, Head of R & D Norway, Confirmit AS Peter Kingston, Consulting Test Manager Howard Knowles, Managing Director of Improvix Ltd Dr Peter May, Technology Consultant, Deloitte Michael G. Norman, Chief Executive Officer of Scapa Technologies Ltd Joanna Nowakowska, Rodan Systems S.A. Martin Phillips, Test Lead, IBM Software Group xiii
- 20. xiv Acknowledgments Graham Thomas,independent testing consultant Nick Sewell, European Managing Director of Ivar Jacobson Consulting Ltd Professor Lucjan Stapp, Warsaw University of Technology Geoff Thompson, Services Director for Experimentus Jon Tilt, Chief Test Architect ESB Products, IBM Software Group Richard Warden, Director of Software Futures Ltd James Wilson, Chief Executive Officer of Trinem I would also like to give particular thanks to Bob Bartlett for his excellent foreword; he is a well-recognized testing industry figure, someone I have great personal respect for, and someone I have had the pleasure of working with on numerous occasions, and I am very grateful for his assistance in providing the foreword to this book. And last, but certainly not least, I would like to express my appreciation for the insight and experience of my technical reviewer Duncan Brigginshaw, and for the constant “encouragement” and guidance from my editor Heather Bergman and her assistant David Jou of Cambridge University Press.
- 21. 1 Introduction If youtry to make the software foolproof, they will just invent a better fool! Dorothy Graham 1.1 Why Agile? In today’s highly competitive IT business, companies experience massive pressures to be as effective and efficient as possible in developing and delivering successful software solutions. If you don’t find strategies to reduce the cost of software devel- opment, your competitors will, allowing them to undercut your prices, to offer to develop and deliver products faster, and ultimately to steal business from you. Often in the past, testing was an afterthought; now it is increasingly seen as the essential activity in software development and delivery. However, poor or ineffective testing can be just as bad as no testing and may cost significant time, effort, and money, but ultimately fail to improve software quality, with the result that your customers are the ones who find and report the defects in your software! If testing is the right thing to do, how can you ensure that you are doing testing right? If you ask managers involved in producing software whether they follow industry best practices in their development and testing activities, almost all of them will confidently assure you that they do. The reality is often far less clear; even where a large formal process documenting best development and testing practice has been introduced into an organization, it is very likely that different members of the team will apply their own testing techniques, employ a variety of different documentation (such as their own copies of test plans and test scripts), and use different approaches for assessing and reporting testing progress on different projects. Even the language is likely to be different, with staff using a variety of terms for the same thing, as well as using the same terms for different things! Just how much time, effort, and money does this testing chaos cost your organiza- tion? Can you estimate just how much risk a project carries in terms of late delivery, with poor testing resulting in the release of poor-quality software? To put this in per- spective, the U.S. National Institute of Standards and Technology recently reported that, for every $1 million spent on software implementations, businesses typically incur more than $210,000 (or between a fifth and a quarter of the overall budget) of 1
- 22. 2 Agile Testing:How to Succeed in an Extreme Testing Environment additional costs caused by problems associated with impact of postimplementation faults [1]. The most common reason that companies put up with this situation is that they take a short-term view of the projects they run; it is much better to just get on with it and “make progress” than to take a more enlightened, but longer-term, view to actually address and fix the problems. Many organizations are now adopting some form of formal test process as the solution to these problems. In this context, a process provides a means of document- ing and delivering industry best practice in software development and testing to all of the staff in the organization. The process defines who should do what and when, with standard roles and responsibilities for project staff, and guidance on the correct way of completing their tasks. The process also provides standard reusable templates for things like test plans, test scripts, and testing summary reports and may even address issues of process improvement [2]. Although there have been numerous attempts to produce an “industry standard” software testing process (e.g., the Software Process Engineering Metamodel [3]), many practitioners and organizations express concerns about the complexity of such processes. Typical objections include: 왘 “The process is too big” – there is just too much information involved and it takes too long to rollout, adopt, and maintain. 왘 “That’s not the way we do things here” – every organization is different and there is no one-size-fits-all process. 왘 “The process is too prescriptive” – a formal process stifles the creativity and intuition of bright and imaginative developers and testers. 왘 “The process is too expensive” – if we are trying to reduce the cost of soft- ware development, why would we spend lots of money on somebody else’s best practices? Interestingly, even where individuals and organizations say they have no process, this is unlikely to be true – testers may invent it on the fly each morning when they start work, but each tester will follow some consistent approach to how he or she performs their testing. It is possible for this “approach” to be successful if you are one of those talented supertesters or you work in an organization that only hires “miracle QA” staff. For the rest of us, we need to rely on documented best practices to provide guidance on the who, the what, and the when of testing, and to provide reusable templates for the things we create, use, or deliver as part of our testing activities. So, here is the challenge: how is it possible to produce good-quality software, on time and to budget, without forcing a large, unwieldy, and complex process on the developers and testers, but still providing them with sufficient guidance and best practices to enable them to be effective and efficient at their jobs? To restate this question, what is the minimum subset of industry best practice that can be used while still delivering quality software?
- 23. 3 Introduction This bookprovides practical guidance to answer this question by means of real- world case studies, and will help you to select, adopt, and use a personally customized set of agile best practices that will enable you and your colleagues to deliver quality testing in as effective and efficient a manner as possible. 1.2 Suggestions on How to Read This Book This book is divided into three main sections (plus the appendices), each of which are closely linked, but each of which can be read and applied separately. Part 1 of the book provides a review of both the traditional or “classic” view of software testing process and examples of agile approaches: 왘 If you are interested in reviewing the early history of software development and testing process, Chapter 2 (Old-School Development and Testing) begins by reviewing the traditional or “classic” view of process. This chapter explores the good and the bad aspects of classic test process, and provides a useful baseline for the rest of the book to build on. 왘 If you are interested in understanding the development of agile approaches to software development and testing, Chapter 3 (Agile Development and Testing) provides an overview of the principal agile approaches that have been used to develop software, with particular emphasis on the testing aspects of the method described. 왘 Although Chapter 3 provides a high-level overview of the principal agile approaches, if you require a deeper understanding of these methods then refer to Appendices A through D. You may find this to be of particular benefit in preparation for reading the agile case studies in Part 2 of the book. Part 2 of the book contains twenty case studies, which provide real-world examples of how different organizations and individual practitioners have worked in an agile development and testing framework or have implemented their own agile testing approaches. Each chapter reviews the specific testing requirements faced by the testers, provides a summary of the agile solution they adopted, describes the overall success of the approach, and provides a discussion of which specific aspects of the approach worked well, and which aspects might be improved or omitted in future testing projects. Part 3 of this book provides an analysis of the agile case studies presented in Part 2 and draws upon the material from Part 1 to make a series of proposals about what components might be used to generate your own successful agile testing process: 왘 If you would like some guidance on agile best practices from a practitioner perspective, Chapter 24 (Analysis of the Case Studies) examines in detail the
- 24. 4 Agile Testing:How to Succeed in an Extreme Testing Environment agile case studies presented in Part 2, identifying particularly successful agile techniques, common themes (such as successful reusable templates), as well as those testing approaches that were not successful and which may need to be treated with caution. 왘 If you are interested in guidance on how to set up your own agile development and testing process, Chapter 25 (My Agile Process) draws on the information provided in the case studies and their analysis to make a series of proposals for how you might set up and run a practical, effective, and efficient agile testing process. 왘 If you would like some guidance on how to introduce your agile testing method into your own organization, Chapter 26 (The Roll-out and Adoption of My Agile Process) provides a series of tried and tested best practices describing how you can roll out the process and drive its successful use and adoption. The Appendices If you would like to find more detail on the agile methods described briefly in Chapter 3, Appendices A through D provide further description of each of the key agile approaches covered in Chapter 3, with particular emphasis on the software quality aspects of each approach. You may find value in reading these appendices in preparation for reading the case studies presented in Part 2 of this book. Appendices E through G provide a set of reusable testing templates that can be used as a resource to be reused in your own agile process (these templates are also available in electronic format from the Cambridge University Press Web site at http://www.cup.agiletemplates.com), including 왘 an agile test script template, 왘 an agile test result record form template, and 왘 an agile test summary report template. Appendix H contains a checklist of agile best practices that shows which practices are particularly appropriate for the different styles and sizes of agile project described in Chapter 25. This checklist can be used as a summary of the practices and as an aide memoire to assist you in populating your own agile process. References cited in the text are fully expanded in the References section at the back of the book.
- 25. PART ONE REVIEW OFOLD-SCHOOL AND AGILE APPROACHES Fact of the matter is, there is no hip world, there is no straight world. There’s a world, you see, which has people in it who believe in a variety of different things. Everybody believes in something and everybody, by virtue of the fact that they believe in something, use that something to support their own existence. Frank Zappa This section of the book provides a review of both the traditional or “classic” view of software testing process and agile approaches. The chapters in this section are: 왘 Chapter 2 – Old-School Development and Testing, which begins by reviewing the traditional or “classic” view of software testing process. This chapter will explore the good and bad aspects of classic test process, and provides a useful baseline for the rest of the book to build on 왘 Chapter 3 – Agile Development and Testing, which provides a review of the most prominent agile approaches that have been used to develop software, with particular emphasis on the testing aspects of the method described. If additional information on a particular approach is needed, more complete details of each method are provided in Appendices A to D. 5
- 27. 2 Old-School Developmentand Testing Testing is never completed, it’s simply abandoned! Simon Mills 2.1 Introduction This chapter discusses what software development and testing process is, reviews the historical development of process, and concludes by providing a review of the elements of a traditional or “classic” software testing process, providing a useful baseline for the rest of the book to build on. 2.2 So, What Is Process? A process seeks to identify and reuse common elements of some particular approach to achieving a task, and to apply those common elements to other, related tasks. Without these common reusable elements, a process will struggle to provide an effective and efficient means of achieving those tasks, and find it difficult to achieve acceptance and use by other practitioners working in that field. Test process is no different; we have many different tasks that need to be achieved to deliver effective and efficient testing, and at a variety of different levels of testing from component/unit/developer testing, through integration/module testing, on into systems testing, and through to acceptance testing [4]. Even before testing process was “invented”, good testers have done things in a particular way to achieve good results – such as the best way to find the most defects, to complete testing more quickly or more cheaply, to save time by reusing things they had produced in earlier testing projects (such as a template for a test plan or a test script), or to ensure consistent nomenclature (such as common terms for testing phases). Such enlightened practitioners were even known to share such best practices with their colleagues, passing on or swapping reusable templates, publishing papers on testing techniques, or mentoring other staff on test management approaches, for example. As the IT industry matured, with customers demanding increasingly complex systems, of ever higher quality, in shorter timescales and with lower cost, the 7
- 28. 8 Agile Testing:How to Succeed in an Extreme Testing Environment Requirements Design Implementation Testing Maintenance Risk Profile 2.1 The Waterfall Phases and Risk Profile (dotted line). resulting commercial pressures forced those organizations developing software to seek methods to ensure their software development was as effective and efficient as possible. If they did not find the means to deliver software faster, cheaper, and with better quality, their competitors would. Successive waves of new technologies, such as procedural programming, fourth- generation languages, and object orientation, all promised to ensure reductions in the occurrence of defects, to accelerate development times, and to reduce the cost of development. Interestingly, it was observed that it was still possible to write poor- quality software that failed to achieve its purpose and performed poorly or included defects, no matter what technologies were used! As with so many instances of a new technology failing to solve a particular problem, the issue actually turns out to be a people problem. Human beings need guidance, they need to build upon the knowledge and experiences of others, they need to understand what works and what doesn’t work, and they need to avoid wasting time reinventing things that other practitioners have already successfully produced and used. Project chaos, where each project and practitioner uses different techniques, employs different terminology, or uses (or worse, reinvents from scratch) different documentation, was increasingly considered to be unacceptable. The following sections review a number of the early approaches to software development and testing that sought to avoid such project chaos. 2.3 Waterfall One of the earliest approaches to software development is the waterfall approach. A paper published by Winston W. Royce in the 1970s [5] described a sequential software development model containing a number of phases, each of which must be completed before the next begins. Figure 2.1 shows the classic interpretation of the phases in a waterfall project.
- 29. 9 Old-School Developmentand Testing From a quality perspective, the waterfall approach has been often criticized because testing begins late in the project; as a consequence, a high degree of project risk (that is, failure of the software to meet customer expectations, to be delivered with acceptable levels of defects, or to perform adequately) is retained until late into the project. With the resultant reworking and retesting caused by the late detection of defects, waterfall projects were also likely to incur additional effort, miss their delivery dates, and exceed their budgets. The waterfall approach has also been criticized for its lack of responsiveness to customer requests for changes to the system being developed. Historically, it was typical for all of the requirements to be captured at the start of the project and to be set in stone throughout the rest of the development. A frequent result of this approach was that by the time the software had been delivered (sometimes months or even years later), it no longer matched the needs of the customer, which had almost certainly changed by then. Because of increasing dissatisfaction with the rigid structure of waterfall projects, other solutions were investigated that would be more flexible in terms of addressing changing requirements. 2.4 Spiral Many attempts were made to address the shortcomings of the waterfall approach, such as the spiral model of software development defined by Barry Boehm in 1988 [6]. Intended for use in large, complex, and costly projects, and intended to address the issues of meeting customer requirements, this incremental development process relied heavily on the development and testing of a series of software prototypes of the final system. The typical steps involved in a spiral model–driven project are as follows: 1. In discussion with the customer, the requirements for the system are defined and documented in as much detail as possible. 2. An initial design is created based on the requirements. 3. A sequence of increasingly complete prototypes are constructed from the design in order to 컄 test the strengths and weaknesses of the prototypes, and to highlight any risks; 컄 assist in refining the requirements by obtaining customer feedback; and 컄 assist in refining the planning and design. 4. The risks identified by testing the prototypes are reviewed with the customer, who can make a decision whether to halt or continue the project. 5. Steps 2 through 4 are repeated until the customer is satisfied that the refined prototype reflects the functionality of the desired system, and the final system is then developed on this basis. 6. The completed system is thoroughly tested (including formal acceptance testing) and delivered to the customer.
- 30. 10 Agile Testing:How to Succeed in an Extreme Testing Environment Cost Release Review Progress 2 . I d e n t i f y & R e s o l v e R i s k s 1 . D e t e r m i n e O b j e c t i v e s 3 . D e v e l o p m e n t & T e s t 4 . P l a n N e x t I t e r a t i o n 2.2 Graphical Overview of the Spiral Model. 7. Where appropriate, ongoing maintenance and test are performed to prevent potential failures and to maximize system availability. Figure 2.2 provides a graphical overview of a typical interpretation of the spiral model. Although considered to be an improvement over the waterfall approach in terms of delivering systems that more closely match the customer’s requirements, and for delivering higher-quality software (achieved in large part by the spiral model, which encourages early and continued testing of the prototypes), issues existed regarding the difficulty of estimating effort, timescales, and cost of delivery; the nondeterministic nature of the cycle of prototype development and testing meant that it was difficult to bound the duration and effort involved in delivering the final product. 2.5 Iterative Iterative models of software development evolved to address issues raised by both waterfall and spiral approaches, with the goal of breaking large monolithic develop- ment projects into smaller, more easily managed iterations. Each iteration would produce a tangible deliverable (typically some executable element of the system under development). The Objectory method [7] provides a good example of such an approach. In 1987, while assisting telecommunications company Ericsson AB with its software
- 31. 11 Old-School Developmentand Testing development efforts, and concerned with the shortcomings of earlier methods, Ivar Jacobson brought together a number of the development concepts he had been think- ing about, such as use cases [8], object-oriented design [9], and iterative development, to create a new approach to developing successful object-oriented applications. The Objectory method supported innovative techniques for requirements anal- ysis, visual modeling of the domain, and an iterative approach to managing the execution of the project. In essence, Objectory would break down a project that might have been run in a large and inflexible waterfall manner into smaller, more easily understood, implemented, and tested iterations. Such an approach brought a number of important benefits for software quality: 왘 Testing could begin much earlier in the project (from the first iteration), enabling defects to be identified and fixed in a timely manner, with the result that timescales were not impacted, and that the effort and cost of fixing and retesting defects were kept low.1 왘 Testing would continue throughout the project (within each iteration), ensuring that new defects were found and fixed in a timely manner, that newly added system functionality did not adversely affect the existing software quality, and verifying that defects found in earlier iterations did not reappear in the most recent iteration. 왘 The valuable visual metaphor provided by use cases and visual modeling enabled the developers and the customer to more easily understand the intention of the system functionality – in effect the customer, analyst, designer, and tester share a common language and understanding of the system. 왘 Testers discovered that the scenarios described by the use cases could very easily be used to design and implement effective test cases2 – the actors (people or other systems) identified in the use cases and their interactions with the system under development, mapped easily onto the steps and verifications needed to develop the test scripts. The Objectory process was organized around three phases: 1. The requirements phase – which involves the construction of three models that describe in a simple, natural-language manner what the system should do: 컄 The use case model – which documents the interactions between the actors and the system, which are typically captured using use case diagrams and natural-language descriptions. 컄 The domain model – which documents the entities within the system, their properties, and their relationships. 1 It is generally considered that for each phase of the project during which you fail to find a bug, the cost of fixing it increases by a factor of 10 [4]. In practice, my experience is that this is a conservative estimate. 2 A test case represents the design for a test. A test case is implemented by means of a test script.
- 32. 12 Agile Testing:How to Succeed in an Extreme Testing Environment 컄 The user interface descriptions – which document the various interfaces between the actors and the system. 2. The analysis phase – which involves the construction of two models that are a refinement of the information captured during the previous phase: 컄 The analysis model – which is a refinement of the domain model produced in the previous phase and which documents behavioral information, control objects (linked to use cases), and entity and interface objects. 컄 The subsystem descriptions – which partition the system around closely coupled and similarly behaving objects. 3. The construction phase – which refines the models produced in the analysis phase. During this phase the following models are generated: 컄 Block models – which represent the functional modules of the system. 컄 Block interfaces – which specify the public operations performed by the modules. 컄 Block specifications – which are optional descriptions of block behavior using finite state machines [10]. In its time, Objectory was considered to be a very successful software development method, and many of its key principles, such as use case analysis and design, continue to be widely used today. In 1991, after having worked closely with the Objectory process for several years, Ericsson AB purchased a major stake in Ivar Jacobson’s company (Objectory Sys- tems), changing its name to Objectory AB. In 1995, Objectory AB merged with the Rational Software Corporation, and shortly thereafter, the Rational Objectory Process version 4.0 was published, which incorporated elements of Grady Booch’s object-oriented analysis and design method [11] and Jim Rumbaugh’s object modeling technique (OMT [12]). Much of the procedural side of the Objectory method (such as use case modeling) was incor- porated into the Rational Objectory Process, with the addition of many notational and diagramming elements from the OMT and Booch methods. Ultimately, through an incremental process of extension and enhancement, the Rational Objectory Process evolved into the Rational Unified Process (RUP) version 5.0, which incorporated modeling and design extensions addressing business engineering, plus best practice guidance on configuration and change management, data engineering, and user interface design. The release of version 7 of RUP provides extensive best-practice guidance on traditional and agile software development and testing methods, such as the ability tooptionally select an“extreme programming”style of development (see Appendix B), as well as the means of customizing the RUP framework to support the user’s own specific agile approaches. The RUP is covered in further detail in Chapter 3, along with a number of other agile approaches.
- 33. 13 Old-School Developmentand Testing Plan Acceptance Tests Plan System Tests Requirements Specification Design Implementation Unit Testing System Testing Acceptance Testing Integration Testing Plan Integration Tests Plan Unit Tests 2.3 The V-Model; Waterfall Phases and Associated Testing Phases. 2.6 Traditional Elements of Test Process The final section of this chapter reviews the typical elements of a traditional testing process, focusing in detail on the relationship between the classic model of testing and the development approaches described in the earlier sections. Many traditional views of software testing are based on the V-model [4], which itself is largely based on the waterfall view of software development. The V-model approach to organizing testing has also been applied to spiral and other models of software development, producing a number of variants, such as the W-model [13]. Figure 2.3 shows a typical interpretation of the V-model. The V-model provides a powerful means of assisting testing practitioners to move testing earlier into the software development life cycle, and to encourage more frequent testing. A major tenet of the V-model is that testing can begin as early as the requirements acquisition phase – with the test manager reviewing the requirements to determine the resources needed for testing, and with the test analyst or designer reviewing the requirements to determine testability and identify errors in the requirements (such as omissions, contradictions, duplications, and items that need further clarification). As a generalization, we can identify four basic test levels or phases associated with the V-model approach to testing:3 1. Unit test (also known as developer or component testing) is typically conducted by the developer to ensure that their code meets its requirements, and is the 3 However, in practice we might also include other variations of the testing phases, such as systems integration testing (often employed where the application under test has a requirement to interact with a number of other independent systems), user acceptance testing, and operations acceptance testing.
- 34. 14 Agile Testing:How to Succeed in an Extreme Testing Environment lowest level of testing normally identified. Historically, unit testing was a manual process (often involving a test harness or some other means of simulating other planned software components that would communicate with the component under test, but which had not been coded at that point). Today, unit testing is usually conducted using one of the many developer testing tools that are available (see, e.g., [14]). 2. Integration test (also known as module testing) is used to demonstrate that the modules that make up the application under test, interface and interact together correctly. As a general rule (but clearly dependent on the size and importance of the project), integration testing is conducted by the developers under the supervision of the project leader. Where a more formal approach to development and testing is being followed, possibly on a large or commercially important project, an independent tester or test team could be involved in conducting integration testing. 3. System test is employed to establish confidence that the (now completed) applica- tion under test will pass its acceptance test. During system testing, the functional and structural stability of the system is examined, as well as the nonfunctional aspects of the application under test, such as performance and reliability. Typi- cally, although again dependent on the size and importance of the project, system testing is conducted by an independent testing team. Often, a customer or user representative will be invited to witness the system test. 4. Acceptance test (also known as user acceptance test or UAT) is used to ensure that the application under test meets its business requirements, and to provide confidence that the system works correctly and is usable before being formally handed over to the end users. Typically, UAT will be conducted by nominated user representatives (sometimes with the assistance of an independent testing representative or team). The role of regression testing is also worth noting; its purpose is to provide confidence that the application under test still functions correctly following a new build or new release of the software (perhaps caused by requests from the customer for modifications or enhancements to the software, or a change to the environment in which the software runs, such as a new release of the underlying operating system). Within each of the test levels or phases, we can identify a number of common elements that they all share. In each testing phase the following must be addressed: 왘 Overview of test phase – providing information on the purpose of the testing phase, its goals, and its characteristics. Information should also be provided relating this testing phase to the appropriate development phase within the V-model and to the adjacent testing phases. 왘 Test phase approach and test data requirements – describing the overall approach to the testing used in this phase (such as white box or black box testing; see [4]),
- 35. 15 Old-School Developmentand Testing and addressing the format, content, and origin of the data required to successfully test the software. 왘 Test planning and resources – providing the plan used to drive the testing con- ducted during this phase, its timescales, milestones, dependencies, risks, and deliverables, as well as information on the resources needed to complete the testing successfully (including both the staff and the physical resources, such as computer equipment). 왘 Roles and responsibilities – specifying the staff required to fulfill the various roles within this phase (such as test team leader, test analyst, or tester) and their specific responsibilities (e.g., “the test analyst shall be responsible for designing and implementing the test scripts required to test the application under test . . . ”). Issues of reporting, management, and liaison should also be specified. 왘 Inputs and outputs – specifying those artifacts (the items created and/or used within phases) required as inputs to this phase to ensure successful testing of the application under test (such as the test plan, the software itself, and the requirements documentation), artifacts created during this phase (such as test designs, test scripts, and test result record forms), and artifacts output from this phase (such as the tested software, completed test result record forms, and the test summary report). 왘 Specific test techniques for this test phase – describing any specific testing tech- niques (such as boundary analysis, equivalence partitioning, or state transition analysis; see [4]) or tools to be used within this testing phase such as test execution tools; see [15]. 왘 Reusable assets – providing test practitioners with access to standard reusable assets (such as test plan, test script, and test summary report templates) that are shared across the project (or even across an organization). These assets can ensure that significant project time, effort, and cost are saved by preventing different practitioners on different projects from reinventing different versions of the same artifacts again and again. Standardization also makes it easier for staff to move between projects without having to relearn a new and different set of project documentation. The preceding information is traditionally recorded in one or more testing docu- ments (usually within the test plan document and the test specification document). Although this approach to software testing has been widely adopted and used, as with the traditional development processes, this classic view of testing process has its critics: 왘 A key criticism leveled against the approach is that it is underpinned by the V-model, which is itself based on the frequently criticized waterfall model of software development. The relevance of the classic view of test process is often questioned when applied to more contemporary, agile views of software develop- ment.
- 36. 16 Agile Testing:How to Succeed in an Extreme Testing Environment 왘 Where the approach is used on small, simple projects with low complexity, prac- titioners often complain that there is “too much process,” and that the reality is that “experienced testers don’t need so much detailed guidance.” In effect, the process itself is criticized for taking too much time and effort to follow. 왘 Paradoxically, the use of a formal and prescriptive testing process may also be criticized for preventing testers from finding defects; many a well-hidden defect has been unearthed by the intuition of a skilled and experienced tester. Testing places high reliance on practitioners who are able to track down defects using their creative and lateral thinking skills, but a highly prescriptive testing solution is often thought to constrain and inhibit such skills. 2.7 Summary Since the earliest days of programming, when engineers manually set noughts and ones on huge electromechanical devices, pioneering practitioners have looked for ways of making the process of developing programs easier, quicker, and more reliable. Once, software was used in just one or two places around the world by a handful of people to implement the complex algorithms needed to decode secret military messages. Now, the world runs on software; it is everywhere – in your home, in your car, in your mobile phone, sometimes even inside you (think about the complex calculations made by heart pacemaker devices or the new generation of intelligent digital hearing aids). Today, a world without software is absolutely unthinkable. As the technologies for developing software have evolved and increasing num- bers of software practitioners have found employment4 in more and more companies, producing ever larger and more complex software systems, the need to find easier, quicker, and more reliable practices for delivering that software has become abso- lutely critical. In the early days, practitioners began to share the successful practices that they had found, often through trial and error, with their colleagues. As the IT industry matured, such best practices began to be documented and distributed, resulting in the appearance of papers and books on waterfall and spiral software development methods, for example. While of initial value in managing relatively simple software projects where cus- tomer requirements were unlikely to change across the duration of the project, many workers became increasingly dissatisfied with these early methods as con- tinuous improvements in the capability of programming technologies encouraged developers to produce systems of ever-increasing size and complexity, and as the number of software disaster stories began to accumulate. 4 It is an incredibly sobering thought that in the 1940s there were just a few people in the entire world who could implement a computer program, but that today each year some 85,000 software engineers leave U.S. universities, with an additional 400,000 Indian graduates joining them, while China’s education system produces some 600,000 developers annually! Inevitably, these numbers can only increase year after year.
- 37. 17 Old-School Developmentand Testing Increasingly, the need to be responsive to changing customer needs, to be able to quickly develop, test, and deliver useful functionality to the customer in a planned and managed incremental manner, the need to reduce the cost and effort of development, and the need to deliver high-quality software led practitioners to challenge the role of traditional approaches to software development and testing. In the twenty-first century, software development needs to be agile; to deliver quality software that meets the customer requirements and that is delivered on time and within budget. Because, bottom line, if you can’t – your competitors will.
- 38. 3 Agile Developmentand Testing Nanos gigantum humeris insidentes – We are but dwarfs standing upon the shoulders of giants. Bernard of Chartres 3.1 Introduction The long history of software development is too frequently characterized by failure rather than by success. When you consider that the practice of software development and testing has spanned two centuries (and arguably three or more centuries1 ), it seems incredible that such a high proportion of projects are unsuccessful. One highly respected industry report, for example, suggested that as many as 76% of all software projects fail to come in on time, to budget, or to customer satisfaction [2]. Growing dissatisfaction with the failure of traditional heavyweight approaches caused a number of workers in the field of software development to begin to question the role of ponderous, inflexible, and frequently ineffective development processes. From the 1980s onward, new lightweight or agile approaches to developing and testing software in an effective and efficient manner began to appear, which chal- lenged the need for cumbersome and ineffectual process. Such approaches frequently focused on the need for good communication in projects, the need to adopt smaller, more easily managed iterations, and the need to be responsive to changing customer requirements. This chapter provides a review of the most prominent agile methods that have been used to develop and test software. Specifically, the agile approaches covered in this chapter include the following: 왘 Rapid Application Development (RAD), 왘 Extreme Programming (XP), 왘 the Dynamic Systems Development Method (DSDM), and 왘 Scrum. Each of these agile approaches is discussed at a relatively high level in this chapter; greater detail is presented in Appendices A through D, respectively. 1 If we include the patterns developed for guiding the actions of weaving machines, for example, or even the astronomical software druids ran on their early silicon and granite hardware systems. 18
- 39. 19 Agile Developmentand Testing The chapter concludes with a brief overview of the key features of a number of other agile methods and approaches, including 왘 the Enterprise Agile Process (previously XBreed), 왘 Ruby on Rails (RoR), 왘 Evolutionary Project Management (Evo), 왘 the Rational Unified Process (RUP), 왘 the Essential Unified Process (EssUP), and 왘 the Software Process Engineering Metamodel (SPEM). Inevitably, this is a snapshot of the agile methods because it is by necessity a very fast-moving subject. 3.2 Rapid Application Development The RAD first appeared in the 1980s, when James Martin developed the approach in response to increasing dissatisfaction with the failure of earlier methods such as the waterfall model of software development [5]. These earlier approaches were characterized by being highly prescriptive, with developers following an inflexible series of development phases in which require- ments were gathered early in the process and then set in stone throughout the rest of the project. Typically, customer involvement was limited to the initial requirements capture and final acceptance testing, resulting in an unacceptably high number of delivered systems that did not match the actual customer needs (which had almost certainly changed since they had been first documented anyway). Cost and time overruns were the norm for such projects and, since much of the testing was left to the later phases, the systems were frequently delivered with major quality issues. Initially inspired by the work of other prominent workers in the field of devel- opment and testing, such as Barry Boehm, Brian Gallagher, and Scott Schults, and following a gestation period of several years, Martin’s thoughts on rapid software development were finally formalized as RAD in his 1990 book, Rapid Application Development [16]. The key goals of RAD are 왘 high-quality systems, 왘 fast development and delivery, and 왘 low costs. RAD seeks to break down the approach taken in monolithic waterfall projects into smaller iterative steps, increasing the opportunities for the customer to be involved in the development and to be exposed to earlier prototypes and working increments of the developing system. In fact, the development of software prototypes is a key aspect of RAD, providing a means of exploring the customer needs for the system through informal testing and managing customer expectations of how the final delivered system should look and perform.
- 40. 20 Agile Testing:How to Succeed in an Extreme Testing Environment RAD proved to be of benefit over traditional development approaches in a number of areas: 왘 RAD’s iterative approach to developing software meant that testing could begin earlier in the development process and could continue more frequently through- out the project. This approach significantly reduced the risk of late identification of serious defects and the associated cost overruns and late delivery frequently seen in waterfall projects. 왘 Closer customer involvement in the development process, with early opportuni- ties to test how well the software met customer needs using the prototypes, meant there were less show-stopping surprises when the system was finally delivered. 왘 Accepting that requirements would no longer be set in stone at the very begin- ning of the project and that changes could be managed effectively through- out the development using requirements planning workshops and joint applica- tion design workshops, helped ensure the delivered software would more closely match customer expectations. 왘 Tighter project management of development priorities, costs, and timescales through the use of techniques such as time boxing [17] kept project progress on track and controlled the extent that the development could get out of control. On the down side, for many practitioners who followed more traditional software development models, RAD gained the reputation of being an excuse for “hacking” or “opportunistic coding,” as it has also been called [18]. It is possible that, as one of the earliest agile methods, RAD may have been perceived as having less rigor than the more established approaches. Also, RAD’s focus on developing a series of rapid prototypes, many of which inevitably would not be carried forward into the final deliverable, was often blamed for wasting time and effort and jeopardizing progress. Finally, the process of prototyping was often poorly implemented due to a weak understanding of what prototyping actually involved [19], leading to a poor perception of the technique. Despite some suspicion from the defenders of the more traditional development methods, RAD arguably set the scene for the development of a number of the later agile methods. Appendix A contains further details of the rules and practices of RAD. 3.3 Extreme Programming In the early 1990s, Kent Beck, a practitioner in the field of software development, had begun to consider how the process of developing software could be made simpler and more efficient. In March 1996 Kent embarked upon a project with a major automotive customer that would employ a number of the software development and testing concepts that he had been considering; the result was the genesis of Extreme Programming (XP [20]).
- 41. 21 Agile Developmentand Testing XP emphasizes customer satisfaction as one of its key drivers; the methodology aims to deliver the software the customer needs when they need it. XP seeks to improve project success in four important areas: 1. Communication – XP encourages the team developing and testing the software to maintain effective and frequent communication both with the other members of the team and with the customer. 2. Simplicity – XP promotes the ideal of simple, clear, and understandable design, translated into similarly clear and understandable code. Even though the cus- tomer may not get to see the source code, XP encourages programmers to develop elegant and effective software solutions of which they can be proud. 3. Feedback – throughout the development project, the programmers obtain feed- back on their work from other programmers and, crucially, the customer, who is exposed to early deliverables as soon in the project as possible. 4. Courage – programmers are empowered to respond positively and proactively to changing customer requirements and changes in the development environment (such as availability of new technologies). By embracing these four principles, development projects are more agile and responsive; better communication across the team means that the developing system is integrated more easily and with fewer errors, plus the improved communication with the customer combined with good feedback ensures that the delivered software more closely matches the users’ needs. From a software quality perspective, XP emphasizes the importance of effective and efficient testing. An important goal of testing in XP is that test development should begin even before any code has been written, continuing throughout the coding process, and following code completion. As defects are found, new tests are developed and are added to the growing test suite to prevent the same bug from reappearing later and getting through to the delivered software. Appendix B contains further details of the rules and practices of XP. 3.4 The Dynamic Systems Development Method Developed in the United Kingdom in the 1990s by a consortium of organizations and agile practitioners, the Dynamic Systems Development Method (DSDM) is an agile framework that builds upon the principles of RAD. DSDM is based on an iterative development model, which seeks to be responsive to changing customer requirements, and which aims to implement the business requirements on time, to budget, and with acceptable levels of quality. The DSDM is typically applied to information systems projects that are charac- terized by challenging timescales and budgets, and seeks to address many of the common reasons for information systems project failure, including exceeding bud- gets, missed delivery deadlines, poor quality, lack of user involvement, and lack of senior management commitment.
- 42. 22 Agile Testing:How to Succeed in an Extreme Testing Environment The DSDM is founded upon nine key principles: 1. Active user involvement is imperative. 2. DSDM teams must be empowered to make decisions. 3. The focus is on frequent delivery of products. 4. Fitness for business purpose is the essential criterion for acceptance of deliver- ables. 5. Iterative and incremental development is necessary to converge on an accurate business solution. 6. All changes during development are reversible. 7. Requirements are baselined at a high level. 8. Testing is integrated throughout the life cycle. 9. A collaborative and cooperative approach among all stakeholders is essential. These principles were framed by combining the agile best practices and experi- ences of the DSDM consortium members. The first draft of the DSDM framework was delivered in January 1995, followed in February that year by formal publication of the framework [21]. Within its overall iterative approach, a DSDM project is structured into three distinct phases: 1. Preproject phase – this 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 definition of the business problem to be addressed, budget and resourcing, outline scope and plans for the feasibility study, and a decision whether or not to proceed with the project. 2. Project life cycle phase – this phase combines both sequential and iterative stages, which drive the incremental development of the system. Following the initial feasibility and business study stages, the project iterates through the functional model iteration, design and build iteration, and implementation stages. 3. Postproject phase – this phase covers postdelivery activities such as maintenance, enhancements, and software fixes, and is used to ensure the ongoing effective and efficient operation of the delivered system. In terms of its continuing adoption and use, DSDM seems to have been more successful at being accepted by senior management than earlier agile approaches such as RAD due to the perception that it represents a more mature and formal agile method. This perception is further reinforced as a result of the frequent integration of DSDM and the PRINCE2 (PRojects IN Controlled Environments) project manage- ment method [22]. As a result, more conservative senior managers have been more receptive to the use of DSDM on larger/higher-profile projects with the result that a substantial and vigorous user population has been established around the globe. The DSDM has also proven to be popular with development and testing prac- titioners, who have continued to refine and enhance the method; since its initial
- 43. 23 Agile Developmentand Testing publication in 1995, DSDM has continued to evolve, incorporating new best prac- tices and technologies wherever appropriate. Appendix C contains further details of the principles and practices of DSDM. 3.5 Scrum Scrum is a project management method for agile software development and testing that enables the creation of self-organizing teams by encouraging co-location of all team members (including customer representatives) combined with effective verbal communication among all team members and across all disciplines that are involved in the project. A key principle of Scrum is the recognition that during a project, the customers are likely to change their minds frequently about what they want and need (often called requirements churn), and that such customer needs cannot be addressed successfully in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach – accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements. In terms of the genesis of Scrum, as early as 1986 Takeuchi and Nonaka [23] had observed that projects employing small, cross-functional teams were typically the most successful, and they coined the phrase “rugby approach” to describe the phenomenon. The first explicit reference to Scrum2 in the context of software devel- opment came in 1990 in work by DeGrace and Stahl [24]. In the early 1990s, work on agile methods by Ken Schwaber and Jeff Sutherland, at their respective companies Advanced Development Methods and Easel Corporation, led Sutherland and Schwaber to jointly present a paper at the 1996 International Conference on Object-Oriented Programming, Systems, Languages, and Application describing Scrum [25]. Schwaber and Sutherland collaborated during the following years to further develop and document their experiences and industry best practices into what is now known as Scrum. In 2001, Ken Schwaber teamed up with Mike Beedle to write up the method in Agile Software Development with SCRUM [26]. A major factor in the success of Scrum projects is the drive for efficient commu- nications, with techniques such as daily short focused stand-up meetings combined with explicit team roles (e.g., Pig and Chicken; see Appendix D) to manage who may contribute to the meetings and in what manner. Although Scrum was originally intended to be used for the management of software development projects, it can be employed in running software maintenance teams or as a program management approach: Scrum of Scrums. Appendix D contains further details of the rules and practices of Scrum. 2 Scrum: a play in the ball game rugby in which two groups of players mass together around the ball and, with their heads down, struggle to gain possession of the ball. Typically held following an illegal forward pass.
- 44. 24 Agile Testing:How to Succeed in an Extreme Testing Environment 3.6 Other Agile Methods This section provides a high-level overview of the key features of a number of other agile methods and approaches to software development and testing. By necessity, this is only a snapshot of the current popular methods and does not seek to be a comprehensive catalog of all agile approaches. Because this subject evolves so quickly, it is recommended that the reader also refer to [26] as a useful source of updates on agile methods. 3.6.1 The Enterprise Agile Process (formerly XBreed) Developed by Mike Beedle with the goal of developing “reusable software in record time,” this twenty-first-century agile approach combines a number of best practices from other agile methods, such as XP and Scrum. Specifically, EAP [28] employs best practices from Scrum as the basis of its management framework and incorporates a subset of XP techniques for its development process. A key feature of the method is the use of design patterns to create reusable objects; EAP creates a library of components that can be easily reused in new software projects to save time, effort, and cost of development and testing, while improving quality by the reuse of “tried and tested” components. The EAP development process promotes the use of well-trained, skilled, and experienced practitioners to populate its teams, and encourages the use of effective knowledge transfer between team members, which, combined with a low communi- cation overhead, helps keep the project running smoothly and efficiently. 3.6.2 Ruby on Rails Created by David Heinemeier Hansson from his earlier work on the Basecamp web- based project management tool [29], Ruby on Rails (RoR [30]) is an open-source web framework that is optimized for “programmer happiness and sustainable productiv- ity.” Typically used by developers for relatively short client-driven web development, and often referred to as “Rails,” RoR use is guided by two key principles: 왘 Convention over configuration (CoC) – In effect development by exception, the benefit of CoC is that only the unconventional aspects of the application need to be specified by the developer, resulting in reductions in coding effort. For example, if the developer creates a class “Part” in the model, the underlying database table is called “Parts” by default. It is only if one deviates from this convention, such as calling the table “parts_on_hand,” that specific code needs to be written that utilizes these names. 왘 Don’t repeat yourself – RoR promotes an approach where information is located in a single, unambiguous place. For example, using the ActiveRecord module of RoR, the developer does not need to explicitly specify database column names in class definitions. Instead, RoR can retrieve this information from the database.
- 45. 25 Agile Developmentand Testing Using the model-view-controller architecture [31] for organizing application programming, RoR incorporates a number of tools: 왘 scaffolding, for simplifying the generation of basic Web site models and views; 왘 WEBrick, a simple RoR web server; and 왘 Rake, a simple build system. By providing these tools combined with an agile development philosophy, RoR can be seen as an example of a highly agile integrated development environment. First released to the public in July 2004, RoR continues to find supporters in the web developer community with an impressive list of adopters (since 2007 RoR has been shipped by Apple with MacOS X v10.5 Leopard, for example). 3.6.3 Evolutionary Project Management Developed by Tom and Kai Gilb, Evolutionary Project Management (Evo [32]) is a twenty-first-century agile project management method whose focus is on earlier delivery of critical results and on-time delivery of deadlined results. Evo is claimed to be able to provide more control over software quality, project performance, and project costs than more traditional project management methods. Evo is particularly suited to developing large-scale software systems, involving complex technology and in rapidly moving environments. Evo aims to be highly responsive and adaptable to unforeseen circumstances while delivering rapid results. Evo follows ten key process principles:3 1. Real results, of value to real stakeholders, will be delivered early and frequently. 2. The next Evo delivery step must be the one that delivers the most stakeholder value possible at that time. 3. Evo steps deliver the specified requirements, evolutionarily. 4. It is impossible to know all the right requirements in advance, but it is possible to discover them more quickly by attempts to deliver real value to real stakeholders. 5. Evo is holistic systems engineering; all necessary aspects of the system must be complete and correct, and delivered to a real stakeholder environment. It is not only about programming, it is about customer satisfaction. 6. Evo projects will require an open architecture, because project ideas will change as often as needed to really deliver value to the stakeholders. 7. The Evo project team focuses their energy, as a team, toward success in the current Evo step. They succeed or fail in the current step together. They do not waste energy on downstream steps until they have mastered current steps successfully. 8. Evo is about learning from hard experience, as fast as possible – what really works and what really delivers value. Evo is a discipline to make teams confront project problems early, but one that delivers progress quickly when provably, the team have got it right. 3 Sincere thanks to Tom and Kai Gilb for allowing me to reproduce this information.
- 46. 26 Agile Testing:How to Succeed in an Extreme Testing Environment 9. Evo leads to early, and on-time, product delivery – both because of selected early priority delivery and because the team learns to get things right early. 10. Evo should allow teams to validate new work processes and get rid of bad ones early. Benefits cited by Evo users include reducing the duration and cost of require- ments capture by 75% over traditional methods, reducing the integration effort to upgrade from a previous code platform to a new code platform from hours to min- utes, and improvements in the motivation, enthusiasm, and morale of developers and testers, leading to significantly higher staff retention. The success of Evo can also be measured by the number of high-profile users (such as IBM, HP, and Microsoft) that have been involved in learning and using the method. 3.6.4 Rational Unified Process Originally developed by Ivar Jacobson, Grady Booch, and Jim Rumbaugh at Rational Software Corporation, RUP is a use case–driven [7] iterative software engineering process that employs the Unified Modeling Language (UML) notation [33] to incre- mentally develop and deliver software. RUP provides industry best practice guidance on software development and testing to its users through a web browser inter- face, allowing the information to be accessed in a simple and easily distributed manner. The RUP iterations are organized under a number of phases – inception, elab- oration, construction, transition, and production – with development and testing activities grouped as a series of disciplines that run across the phases. These typically include business modeling, requirements, analysis and design, implementation, test, deployment, operations and support, configuration and change management, project management, environment, and infrastructure management. RUP provides comprehensive information on all aspects of software development, including project roles and responsibilities, project planning and management, tasks and timescales, inputs and outputs, testing techniques and approaches, reusable project templates (such as test plan and test script templates), metrics, and guidance on process improvement. RUP explicitly supports agile approaches by providing a customizable metamodel that allows users to select from the RUP best practices to create and maintain their own subset of agile best practices. RUP also provides access to predefined agile customizations, such as its XP process plug-in. With its early origins in Ivar Jacobson’s 1990s Objectory process [7], the devel- opment of RUP has been a highly inclusive process, and it has drawn from many sources including the experience of major industry experts, special interest groups, industry standards and guidelines, and the experiences of many thousands of ordinary practitioners.
- 47. 27 Agile Developmentand Testing Over the years, RUP has spawned a number of other agile methods and initiatives, such as the EssUP [34] and the Object Management Groups SPEM. 3.6.5 The Essential Unified Process The EssUP [34] is a continued development of the work begun in RUP by process guru Ivar Jacobson, which identifies and promotes the use of a number of essential practices that include use cases, iterative development, architecture-driven design, team practices, and process practices, plus process improvement (through Capability Maturity Model Integration [35]) and agile development. Adoption and use of EssUP are accelerated through the use of a set of “playing cards” – concise ready reference cards documenting the process best practices in a simple and highly accessible manner. Chapter 5 contains examples of these cards, and Figure 5.1 shows the Test Case and Test Results cards. EssUP appears to be gaining in popularity and use, with both IBM and Microsoft incorporating its best practices into their respective process product offerings. 3.6.6 The Software Process Engineering Metamodel SPEM [3] is, as its name suggests, a process metamodel that allows users to develop and maintain their own specific development and testing process. SPEM is administered by the Object Management Group (OMG [36]) and based on the RUP metamodel, which the Rational Corporation donated to OMG for the purpose of supporting the development of a widely available open-source software process engineering metamodel. Employing the UML notation [33], SPEM provides facilities for individual devel- opment and testing practitioners to create their own specific development method that incorporates those process elements appropriate to their own particular devel- opment needs and requirements. 3.7 Summary Having worked in the software business for more than thirty years, I must admit to wondering if anyone will ever be completely satisfied with a particular means of developing and testing software. It seems that, since the earliest days of process development, there have been practitioners who have either thought the resulting process was too lightweight or too heavyweight, that it guided them to do their job or constrained their creativity, that it gave them the freedom to use industry best practice or clipped their developer and/or tester wings. I have often wondered if a major issue driving the development of new agile methods is a desire for IT practitioners to express their own individuality and their own creativity; even where perfectly usable and successful agile methods like Scrum
- 48. 28 Agile Testing:How to Succeed in an Extreme Testing Environment and XP are available, there will be developers and testers who still find the need to pare these down to a subset of “essential” agile techniques, and to then add some bits of their own to form their own unique process. On the other hand, it is an absolute fact that there are no two software projects that are exactly the same: 왘 There will be different-sized projects, with different-sized budgets and varying available resources (the case studies in Part 2 of this book illustrate this point well). 왘 The software being developed could be for internal use only, could represent a bespoke development for a customer, or could be a product offered for sale to numerous customers. 왘 The software might be being developed for a safety-, business-, or security-critical application. 왘 The speed of execution of the software may not be an issue, or the software might need to execute in real time or might need to be delivered as an embedded or pervasive solution. Since there is no “one-sized” project, it is fair and reasonable to say that there can be no one-size-fits-all process. Viewed in this way, it seems entirely natural, even necessary, that diligent IT practitioners would find the need to define and document project-specific best practices for their own use and for that of their colleagues. The case studies presented in the next section of this book provide an excellent illustration: real-world IT practitioners, working on unique projects, facing the need to deliver solutions in an agile manner, and needing to find their own interpretations of agile best practices. In many of the cases studies, the authors have started from a point of adopting or using an established agile method, but have then had to modify or enhance the method to more closely meet the unique requirements of their particular project. The third section of this book provides an analysis of the case studies, looking for common themes, identifying agile best practices that provided significant benefits to the project, highlighting agile methods whose use may need to be challenged in certain circumstances, and making a proposal for how you can quickly, easily, and successfully build and use your own effective and efficient agile process.
- 49. PART TWO EVERYONE ISDIFFERENT: AGILE CASE STUDIES People think computers will keep them from making mistakes. They’re wrong, with computers you just make mistakes faster. Adam Osborne This section of the book contains twenty real-world case studies from organizations or individuals who have adopted and used existing agile methods or who have developed their own agile approaches to software testing. Each case study follows a standard format and concludes with advice on what aspects of the approach worked well and what aspects might be improved or removed in future testing projects. The headings include 왘 The case study title, author name(s), and a brief synopsis of the case study; 왘 Introduction – introducing both the author and the case study; 왘 Overview of the Testing Challenge – describing the particular testing challenges that needed to be addressed in this case study; 왘 Definition of the Agile Testing Process – providing details of the particular agile testing solution employed in this case study; 왘 Results of the Agile Approach – describing the outcome of the project and of the agile approach used in this case study; and 왘 Lessons Learned – documenting the lessons learned during the project, including what agile practices worked well, what could be improved in future projects, and what practices should be treated with caution. The following quick reference table provides a summary of the characteristics of each case study to make it as easy as possible for you to identify case studies that most closely match your own testing needs. 29
- 50. Case Study QuickReference Table Case Test study Market Language Platform O/S Proj Size Automation Author 1 (C4) Survey & Reporting Solutions Java Web Various Medium Yes Gilb & Johansen 2 (C5) Government Various Various Various Large Yes Nick Sewell 3 (C6) Finance C++ PC WinXP Small No Graham Thomas 4 (C7) Telecoms Citrix PC Server Win2K Large No Michael G. Norman 5 (C8) Finance C VAX VMS Medium Yes Nick Denning 6 (C9) Life Assurance Java Web Various Medium No Geoff Thompson 7 (C10) Finance VB6–VB.net PC WinXP Large Yes Howard Knowles 8 (C11) Retail Java Websphere Various Medium Yes Colin Cassidy 9 (C12) Various Java Various Various Medium No Martin Phillips 10 (C13) Various Various Various Various Various Yes Stephen K. Allott 11 (C14) Various Java PC Various Medium Yes James Wilson 12 (C15) Finance Eclipse Java Windows WinXP Offshore Yes Peter Kingston 13 (C16) Trading Systems Various Wndows Small Limited Java Richard Warden & Unix 14 (C17) Professional Services .NET WebServer WinXP Medium No David Evans 15 (C18) Various Fortune500 Java Mainframe Intel & Unix Large Yes Jon Tilt 16 (C19) Various Various Various Various Various No Isabel Evans 17 (C20) Wiki Lotus Notes Web Web Small No Dass Chana 18 (C21) SOA Various Various Various Various Yes Greg Hodgkinson 19 (C22) Research Java PC Windows Research No Lucjan Stapp and Joanna Nowakowska 20 (C23) Media C# .NET Win Server 2003 Medium No Peter May
- 51. 4 From Waterfallto Evolutionary Development and Test Tom Gilb and Trond Johansen SYNOPSIS Evolutionary Development (Evo) focuses on early delivery of high value to stakeholders and on obtaining and utilizing stakeholder feedback. This case study describes, from a project manager’s viewpoint, the results that one organization rapidly achieved after switching from using a waterfall approach to Evo. The major benefits of adopting an Evo approach come from reducing the duration of the requirements phase from four to five weeks down to just one week, and from paying greater attention to the quality requirements as opposed to the previous practice of concentrating solely on the required functionality, resulting in a happier workforce, happier clients, and more business. 4.1 Introduction My name is Tom Gilb and I am an independent testing consultant and author of Competitive Engineering: A Handbook for Systems & Software Engineering Man- agement using Planguage (2005), Principles of Software Engineering Management (1988), and Software Inspection (1993). My book Software Metrics (1976) coined the term and was used as the basis for the Software Engineering Institute Capability Maturity Model Level Four (SEI CMM Level 4 [37]). My most recent interests are development of true software engineering and systems engineering methods. In 1997 Kai Gilb and I published a book entitled Evo: The Evolutionary Project Management and Product Development Handbook, describing an agile software development and testing project management method [32]. Evo is an iterative method in which a series of small delivery steps are taken until the project goals are reached and the software delivered. Key differences between Evo and other project management methods include an emphasis on achieving the requirements over slav- ishly following formal processes, and the focus on ensuring that testing starts early in the process, is conducted in each of the steps, and continues throughout the project. This case study will focus on the adoption and use of the Evo method in the devel- opment of the Confirmit √ product from Oslo-based company Confirmit AS, which is where co-author Trond Johansen works as the head of project management. 31
- 52. 32 Agile Testing:How to Succeed in an Extreme Testing Environment Specifically, this case study focuses on the role and use of Evo in reducing the integration effort and timescales for developments and enhancements made to the Confirmit √ product, as compared with the previously used waterfall-based [5] devel- opment process. 4.2 Overview of the Testing Challenge Confirmit √ is a powerful web-based software package that enables organizations to gather, analyze, and report on key business information across a broad range of commercial applications. Some twenty staff (including a quality assurance team of three people) work in the Confirmit AS research and development department and have responsibility for developing the core Confirmit √ functionality, as well as for developing custom bespoke modules for specific clients. Early in the company’s history, when Confirmit AS had just a few clients, the development process was fairly ad hoc and customer-driven. Changes to the software were made on an almost daily basis, driven by client feedback, and while this deliv- ered stakeholder value quickly, the process also resulted in numerous defects, long working hours, and poor control of the software development and testing process. As the Confirmit √ client base grew, Confirmit AS was faced with the need to become more effective and efficient in its development and testing of the product; it was clear that a more formal process was needed. Initially, Confirmit AS looked to adopt a waterfall approach, incorporating pro- cess improvement via the Capability Maturity Model (CMM [37]). After following a waterfall approach for a number of years, a number of issues were identified: 왘 Risk discovery and mitigation was delayed until the later stages of the project. 왘 Document-based verification was postponed until the later stages of the project. 왘 There was dissatisfaction with the need to stipulate unstable requirements too early; requirements change is perceived as a bad thing in waterfall. 왘 Operational problems were discovered far too late in the process (typically at acceptance testing). 왘 There were lengthy modification cycles and too much rework and retesting. 왘 Most important, the requirements were nearly all focused on functionality, not on the quality attributes of the system. With increasing dissatisfaction with their waterfall approach, Confirmit AS began to work closely with Tom and Kai Gilb to roll out and adopt an Evo approach in order to improve their development process for Confirmit √ . In particular, three key goals were identified: 왘 Reducing the integration effort – that is, the amount of effort for each developer to get the latest build to work on his or her workstation so that they were able to code against the latest code platform;
- 53. 33 From Waterfallto Evolutionary Development and Test 왘 Reducing the time in minutes to upgrade – from a previous code platform to the most recent code platform from the past figure of three hours to a goal of two minutes; and 왘 Improving the reliability of builds – which historically had been an area where there had been significant quality issues. Historically, the Confirmit AS development process for the Confirmit √ product had focused mostly on functional requirements, but with Evo the requirements process changed with the realization that it is the product quality requirements that provide Confirmit AS with a competitive advantage over its rivals. 4.3 Definition of an Agile Testing Process While Section 3.6.3 provides a summary of the Evo process principles, the Confirmit AS interpretation of the Evo method was as follows: 왘 Identify stakeholders – end users, superusers, support, sales, IT operations, etc. 왘 Define stakeholders’ real needs and the related product qualities – what was actually needed to support their business needs. 왘 Identify past/status of product qualities and your goal – that is, how much you want to improve. 왘 Identify candidate solutions for meeting your goals. 왘 Develop a step-by-step plan for 컄 delivering improvements to the process, and hence the product; 컄 providing deliveries every week (with respect to stakeholder needs and product quality goals); and 컄 measuring progress: are we moving towards our goals (again, with respect to stakeholder needs and product quality goals)? Guided by Evo, Confirmit AS put in place a new requirements standard that meant that requirements had to 왘 be clear and unambiguous, 왘 be testable, 왘 be quantified, 왘 not involve solutions, and 왘 have a stakeholder focus. The focus with requirements had to be on the day-to-day operations of the Confirmit √ users and not represent a list of what they might or might not like. Following this process, all of the requirements for a new release of Confirmit √ were defined and documented in just one week, as compared to the previous norm of four to five weeks.
- 54. 34 Agile Testing:How to Succeed in an Extreme Testing Environment In terms of Evo cycle time, a one-week-long Evo step was adopted in which the key activities were as follows: 왘 On the Friday: 컄 The Project Manager (PM) delivers the detailed plan for the next week’s version of the software (let’s call it Version N) to the customer Chief Technical Officer (CTO) prior to attending a weekly project management meeting. 컄 The CTO reviews and approves or rejects the design and records their com- ments. 컄 The PM and CTO attend the weekly project management meeting to discuss the Version N detailed plan and review CTO comments. 컄 The developers focus on general maintenance and documentation tasks. 컄 The QA team runs final build and setup for that week’s developed version (let’s call it Version N-1), installs setup on test servers, and performs initial crash test1 of Version N-1 prior to its release. 왘 On the Monday: 컄 The developers first generate the tests required to validate Version N and then begin development of the code. 컄 The QA team reviews the results of the continuous integration (CI) process and reviews test plans and tests for Version N. 컄 The users begin to use Version N-1 and compile feedback for the developers. 왘 During Tuesday and Wednesday: 컄 The developers continue to generate the tests required to validate Version N and develop the associated code. 컄 The developers meet with the users to discuss the feedback from using Version N-1. 컄 Incorporating the feedback from the users, the developers continue to gen- erate the tests required to validate Version N and develop the associated code. 컄 The QA team reviews the results of the CI process and reviews test plans and tests for Version N. 왘 On the Thursday: 컄 The developers complete the final tests for Version N, code, and execute the tests. The developers also complete the graphical user interface tests for the previous week’s version of the software (let’s call this Version N-2). 컄 The QA team reviews the results of the CI process and reviews test plans and tests for Version N. 1 A testing technique used to determine the fitness of a new build or release of the application under test to undergo further, more thorough testing [4].
- 55. Another Random Documenton Scribd Without Any Related Topics
- 56. Cardinal de Granvelle(Collection de Documents inédits, Paris, 1841-52); Furnivall, Ballads from Manuscripts (Ballad Society, London, 1868); Four Supplications of the Commons, and Thomas Starkey, England under Henry VIII. (Early English Text Society, 1871); Strype, Ecclesiastical Memorials and Life of Cranmer (Oxford edition, 26 vols. 1820, etc.); Liturgies of Edward VI. (Parker Society, Cambridge, 1844); Stow Annals (London, 1631). Later Books in addition to those given on p. 313: Pollard, England under Protector Somerset (London, 1900); Burnet, History of the Reformation (Oxford edition, 1865); Dixon, History of the Church of England (London, 1893); Gasquet and Bishop, Edward VI. and the Book of Common Prayer (London, 1890). Cambridge Modern History, ii. xiv. [476] Pollard, Cambridge Modern History, ii. 474. [477] These Injunctions, and the Articles of Inquiry which interprets them, are printed in Strype, Ecclesiastical Memorials, etc. (Oxford, 1822) II. i. pp. 74-83. [478] Cranmer, Miscellaneous Writings and Letters (Parker Society Cambridge, 1846), p. 128. [479] English Historical Review for 1904 (January), pp. 98 ff. [480] This Act, entitled Act against Revilers, and for receiving in both Kinds, is printed in Gee and Hardy, Documents, etc. p. 322. [481] Gee and Hardy, Documents, etc. p. 328. [482] Ecclesiastical Memorials, etc. II. i. p. 133. It is printed in The Two Liturgies, with other Documents set forth by Authority in the Reign of King Edward the Sixth (Parker Society, Cambridge, 1844), p. 1. [483] The book is printed in The Two Liturgies, etc., of the Parker Society, pp. 9 ff. [484] Gee and Hardy, Documents, etc. pp. 358 ff. [485] Mr. Pollard (Cambridge Modern History, ii. pp. 478, 479) thinks that the influence of these foreign divines on the English Reformation has been overrated; and he is probably correct so far as changes in worship and usages go. His idea is that the English Reformers followed the lead of Wiclif, consciously or unconsciously, rather than that of continental divines; but if the root-thought in all Reformation theology be considered, it may be doubted whether Wiclif could supply what the English divines had in common with their continental contemporaries. “Wiclif, with all his desire for Reformation, was essentially a mediæval thinker.” The theological question which separated every mediæval Reformer from the thinkers of the Reformation was, How the benefits won by the atoning work of Christ were to be appropriated by men? The universal mediæval answer was, By an imitation of Christ; while the universal Reformation answer was, By trust in the promises of God (for that is what is meant by Justification by
- 57. Faith). In theiranswer to this test question, the English divines are at one with the Reformers on the Continent, and not with Wiclif. [486] Pollard, England under Protector Somerset (London, 1900). [487] “Tulchan is a calf skin stuffed with straw to cause the cow to give milk. The Bishop served to cause the bishoprick to yeeld commoditie to my lord who procured it to him.” Scott’s Apologetical Narration of the State and Government of the Kirk of Scotland since the Reformation (Woodrow Society, Edinburgh, 1846), p. 25. [488] The book is printed in The Two Liturgies, with other Documents, etc. (Parker Society), p. 187. [489] Gee and Hardy, Documents, etc. p. 371. [490] Compare The Two Liturgies, etc. (Parker Society) p. 283. [491] Ibid. pp. 92, 279. [492] Gee and Hardy, Documents, etc. p. 269. [493] Original Letters relative to the English Reformation (Parker Society, Cambridge, 1847), ii. 566. [494] Original Letters, etc. (Parker Society) ii. 568, Macronius to Bullinger (August 28th, 1550). [495] Sources in addition to those on pp. 351: Epistolæ Reginaldi Poli, S. R. E. Cardinalis, 5 vols. (Brixen, 1744-57); Chronicle of Queen Jane and of two years of Queen Mary, and especially of the Rebellion of Sir Thomas Wyat, written by a Resident in the Tower of London (Camden Society, London, 1850); Garnett, The Accession of Queen Mary; being the contemporary narrative of Antonio Guaras, etc. (London, 1892). Later Books: Stone, History of Mary I., Queen of England (London, 1901); Ranke, Die römischen Päpste (Berlin, 1854); Hume, Visit of Philip II. (1554) (English Historical Review, 1892); Leadam, Narrative of the Pursuit of the English Refugees in Germany under Queen Mary (Transactions of Royal Historical Society, 1896); Wiesener, The Youth of Queen Elizabeth, 1533-58 (English translation, London, 1879); Zimmermann, Kardinal Pole sein Leben und seine Schriften (Regensburg, 1893). [496] Gee and Hardy, Documents, etc. p. 373. [497] The Act of Parliament is printed in Gee and Hardy, Documents, etc. p. 377. [498] Philip’s marriages had this peculiarity about them, that his second wife (Mary) had been betrothed to his father, and his third wife had been betrothed to his son.
- 58. [499] Strype, Memorialsof Queen Mary’s Reign, III. ii. 215. [500] Gee and Hardy, Documents, etc. p. 385. [501] In the days of Henry VIII., Bishop Gardiner had published a book under this title, in which the papal jurisdiction in England was strongly repudiated. Someone, probably Bale, when Gardiner was aiding the Queen to restore that supremacy, had translated the book into English, and had printed at the bottom of the title- page, “A double-minded man is inconstant in all his ways.” [502] Gee and Hardy, Documents, etc. p. 384, The Act de hæretico comburendo will be found on p. 133. [503] Ibid. p. 380. [504] Bonner’s Articles of Inquiry are printed in Strype’s Historical Memorials, Ecclesiastical and Civil, etc. III. ii. p. 217. [505] Gairdner’s The English Church in the Sixteenth Century, etc. (London, 1902) p. 339. [506] Strype, Memorials, Ecclesiastical and Civil, etc. III. i. 221, 223. [507] Ibid. III. ii. 556. [508] Strype, Memorials, Ecclesiastical and Civil, etc. III, i. 222, III. ii, 224. [509] Calendar of State Papers, Domestic Series, of the Reign of Elizabeth, 1601- 3; with Addenda, 1547-65 (London, 1870), p. 483. [510] An account of Cranmer’s trial is given in Foxe, Acts and Monuments (London, 1851), iii. 656 ff. The process is in Cranmer’s Miscellaneous Writings and Letters (Parker Society), pp. 541 ff. [511] Cranmer’s Works, ii. 447 ff. [512] Works, ii. pp. 445-56. [513] Miscellaneous Writings, etc. (Parker Society) p. 563. [514] Pollard, Cranmer, pp. 367-81. [515] Calendar of State Papers and MSS. existing in the Archives and Collections of Venice, 1555-56, p. 386. [516] Pollard, Cranmer, p. 328. [517] There are few more pathetic documents among the State Papers than those thus catalogued: “King Philip and Queen Mary to Cardinal Pole, notifying that the Queen has been delivered of a Prince.”
- 59. “Passport signed bythe King and Queen for Sir Henry Sydney to go over to the King of the Romans and the King of Bohemia, to announce the Queen’s happy delivery of a Prince.” There are several such notifications all ready for the birth which never took place. Calendar of State Papers, Domestic Series, of the reigns of Edward VI., Mary, Elizabeth, 1547-80 (London, 1856), p. 67. [518] Sources: Calendar of State Papers, Elizabeth, Foreign (London, 1863, etc.); Calendar of State Papers relating to Scotland and Mary Queen of Scots (Edinburgh, 1898, etc.); Calendar of State Papers, Hatfield MSS. (London, 1883); Calendar of State Papers, Venetian, 1558-80 (London, 1890); Calendar of State Papers, Spanish, 1558-67 (London, 1892); Weiss, Papiers d’état du Cardinal Granvelle, vols. iv.-vi. (Paris, 1843-46); Bullarium Romanum, for two Bulls—the one of 1559 (i. 840) and the one deposing Elizabeth (ii. 324); A Collection of Original Letters from the Bishops to the Privy Council, 1564 (vol. ix. of the Camden Miscellany, London, 1893); Calvin’s Letters (vols. xxxviii.-xlviii. of the Corpus Reformatorum); Zurich Letters (two series) (Parker Society, Cambridge, 1853); Liturgies and occasional Forms of Prayer set forth in the Reign of Queen Elizabeth (Parker Society, Cambridge, 1847); Dysen, Queene Elizabeth’s Proclamation (1618). Later Books: Creighton, Queen Elizabeth (London, 1896); Hume, The Courtships of Queen Elizabeth (London, 1896); and The great Lord Burghley (London, 1898); Philippson, La contre-révolution religieuse (Brussels, 1884); Ruble, Le Traité de Cateau-Cambrésis (Paris, 1889); Gee, The Elizabethan Clergy (Oxford, 1898); and The Elizabethan Prayer-Book and Ornaments (London, 1902); Tomlinson, The Prayer-Book, Articles and Homilies (London, 1897); Hardwick, History of the Articles of Religion (Cambridge, 1859); Lorimer, John Knox and the Church of England (London, 1875); Neal, History of the Puritans (London, 1754); Parker The Ornaments Rubric (Oxford, 1881); Shaw, Elizabethan Presbyterianism (English Historical Review, iii. 655); Cambridge Modern History, ii. 550 ff.; Frere, History of the English Church in the Reigns of Elizabeth and James 1558-1625 (London, 1904). [519] Calendar of Letters and State Papers relating to English Affairs, preserved principally in the Archives of Simancas (London, 1892), i. p. 7. [520] Ibid. p. 89. In the same letter the Bishop blames the instructions of the “Italian heretic friars,” i.e. Peter Martyr Vermigli and Ochino; cf. p. 81. [521] Ibid. pp. 1, 4, 5, etc. [522] Ibid. pp. 3, 77. [523] Calendar of Letters and State Papers relating to English Affairs, etc. Introduction, p. lv.
- 60. [524] Calendar ofLetters and State Papers relating to English Affairs, etc. p. 62. [525] Ibid. pp. 39, 67; cf. 83. [526] Cf. Device in Gee’s Elizabethan Prayer-Book, p. 197. [527] Strype, Annals of the Reformation and Establishment of Religion, etc. (Oxford, 1824) I. ii. 389. [528] Gee and Hardy, Documents, etc. p. 416. [529] Goderick’s Divers Points of Religion contrary to the Church of Rome is printed by Dr. Gee in the appendix to his Elizabethan Prayer-Book and Ornaments (London, 1902), pp. 202 ff.; the sentence quoted is on p. 205; the document is also in Dixon’s History of the Church of England, v. 28. [530] Venetian State Papers, 1558-80, 1. [531] Calendar of Letters and State Papers relating to English Affairs, preserved chiefly in the Archives of Simancas, i. 17, 25. [532] Calendar of State Papers, Domestic Series, of the Reigns of Edward VI., Mary, and Elizabeth (London, 1856), i. 123. [533] Calendar of Letters and State Papers relating to English Affairs, preserved chiefly in the Archives of Simancas, i. 25. [534] Ibid. pp. 7, 12. [535] English Historical Review for July 1903, pp. 517, ff.; Dublin Review, Jan. 1903; The Church Intelligencer, Sept. 1903, pp. 134, ff. [536] Cf. Tomlinson, “Elizabethan Prayer-Book: chronological table of its enactment,” in Church Gazette for Oct. 1906, p. 233. [537] Dublin Review, Jan. 1903, p. 48 n: “Ad quem eundem locum (House of Commons) isti convenerunt (ut communis fertur opinio) ad numerum ducentorum virorum, et non decem catholici inter illos sunt reperti.” [538] Zurich Letters, i. 10 (Parker Society, Cambridge, 1842); cf. Calendar of Letters and State Papers relating to English Affairs, preserved principally in the Archives of Simancas, 1558-67, p. 33: “To-morrow it (the Bill) goes to the Upper House, where the bishops and some others are ready to die rather than consent to it.” [539] For “Il Schifanoya” and his trustworthiness, cf. Calendar of State Papers, Venetian, 1558-80, Preface viii. [540] Ibid. p. 52. [541] Canon Dixon (History of the Church of England, v. 67) declares that the phrase “Supreme Head” was not in the Bill. He has overlooked the fact that Heath
- 61. in his speechagainst it quotes the actual words used in the proposed Act: “I promised to move your honours to consider what this supremacy is which we go about by virtue of this Act to give to the Queen’s Highness, and wherein it doth consist, as whether in spiritual government or in temporal. If in spiritual, like as the words of the Act do import, scilicet: Supreme Head of the Church of England immediate and next under God, then it would be considered whether this House hathe authority to grant them, and Her Highness to receive the same” (Strype, Annals, I. i. 405). [542] Calendar of Letters and State Papers relating to English Affairs, preserved chiefly in the Archives of Simancas, 1558-80, pp. 37, 44, 50, 55, 66; Parker’s Correspondence, p. 66; Zurich Letters, i. 33. [543] The Act is printed in Gee and Hardy, Documents, etc. p. 442. [544] The Acts of Henry VIII. which were revived were:—24 Hen. VIII. c. 12—The Restraint of Appeals, passed in 1533; 23 Hen. VIII. c. 20—The conditional Restraint of Annates; 25 Hen. VIII. c. 19—The Submission of the Clergy and Restraint of Appeals of 1534; 25 Hen. VIII. c. 20—The Ecclesiastical Appointments Act; The absolute Restraint of Annates, Election of Bishops, and Letters Missive Act of 1534; 25 Hen. VIII. c. 21—Act forbidding Papal Dispensations and the Payment of Peter’s Pence of 1534; 26 Hen. VIII. c. 14—Suffragan Bishops’ Act of 1534; and 28 Hen. VIII. c. 16—Act for the Release of such as have obtained pretended Dispensations from the See of Rome. These Acts are all, save the last mentioned, printed in Gee and Hardy, Documents, etc. pp. 178-232, 253-56. [545] Ibid. p. 445. [546] Ibid. p. 447. [547] Ibid. p. 446. [548] Ibid. p. 455. [549] The Act is printed in Gee and Hardy, Documents, etc. pp. 458 ff. [550] Gee and Hardy, Documents, etc. p. 371. [551] The Device is printed in Strype, Annals, etc. I. ii. 392, and in Gee’s Elizabethan Prayer Book and Ornaments (London, 1902), p. 195. [552] Gee’s Elizabethan Prayer-Book and Ornaments, pp. 76 f. [553] Zurich Letters, ii. 17. [554] The Journal of the House of Commons, i. 54: “The Bill for the Order of Service and Ministers in the Church” (Feb. 15th); The Book of Common Prayer and Ministration of Sacraments (Feb. 16th). [555] Calendar of State Papers, Venetian, 1558-80, p. 45: “a book passed by the Commons”; cf. above, p. 392; cf. also Bishop Scot’s speech on the reading of the
- 62. Bill which wasemasculated by the Lords, in Strype’s Annals, I. ii. 408. [556] Dr. Gee rejects the idea that Guest’s letter had anything to do with the Book passed by the Commons and rejected by the Lords; cf. his Elizabethan Prayer-Book and Ornaments, pp. 32 ff.; and for a criticism of Dr. Gee, Tomlinson, The Elizabethan Prayer-Book and Ornaments; a Review, p. 12. Guest’s letter is printed by Dr. Gee in his Elizabethan Prayer-Book, etc. p. 152, and more accurately by Mr. Tomlinson in his tract, Why was the First Prayer-Book of Edward VI. rejected? [557] “Il Schifanoya” reports the wrath of the Commons: They “grew angry, and would consent to nothing, but are in very great controversy” (Calendar of State Papers, Venetian, 1558-80, p. 52); cf. p. 392. [558] Journal of the House of Commons, i. 57. [559] Professor Maitland (English Historical Review, July 1903, p. 527 n.) and Father J. H. Pollen (Dublin Review, January 1903) think that this proclamation of the 22nd of March was never issued; but “Il Schifanoya” can hardly refer to any other. [560] “On Easter Day, Her Majesty appeared in the chapel, where Mass was sung in English, according to the use of her brother, King Edward, and the communion was received in both ‘kinds,’ kneeling, facendoli il sacerdote la credenza del corpo et sangue prima; nor did he wear anything but the mere surplice (la semplice cotta), having divested himself of the vestments (li paramenti) in which he had sung Mass; and thus Her Majesty was followed by many Lords both of the Council and others. Since that day things have returned to their former state, though unless the Almighty stretch forth His arm a relapse is expected. These accursed preachers, who have come from Germany, do not fail to preach in their own fashion, both in public and in private, in such wise that they persuaded certain rogues to forcibly enter the church of St. Mary-le-Bow, in the middle of Cheapside, and force the shrine of the most Holy Sacrament, breaking the tabernacle, and throwing the most precious consecrated body of Jesus Christ to the ground. They also destroyed the altar and the images, with the pall (palio) and church linen (tovalie), breaking everything into a thousand pieces. This happened this very night, which is the third after Easter.... Many persons have taken the communion in the usual manner, and things continue as usual in the churches” (Calendar of State Papers, Venetian, 1558-80, p. 57). [561] The speeches of Abbot Feckenham and Bishop Scot, reprinted in Gee’s Elizabethan Prayer-Book, etc. pp. 228 ff., represent the arguments used in the Lords. Scot’s speech was delivered on the third reading of the Act of Uniformity, quite a month after the Westminster conference, and Feckenham’s may have been made at the same time; still they show the arguments of the Romanists. [562] Calendar of Letters and State Papers relating to English Affairs, preserved principally in the Archives of Simancas, 1558-67, pp. 45, 46-48; Zurich Letters, i.
- 63. 13ff.; Strype’s Annals,etc. I. i. 128-40, I. ii. 466; Calendar of State Papers, Venetian, 1558-80, pp. 64, 65. [563] “King Edward’s reformation satisfieth the godly”: Bullinger to Utenhovius (Zurich Letters, 2nd series, p. 17 n.; Strype, Annals, I. i. 259). [564] May 20th, Cox to Weidner: “The sincere religion of Christ is therefore established among us in all parts of the kingdom, just in the same manner as it was formerly promulgated under our Edward of blessed memory” (Zurich Letters, i. 28). May 21st, Parkhurst to Bullinger: “The Book of Common Prayer, set forth in the time of King Edward, is now again in general use throughout England, and will be everywhere, in spite of the struggles and opposition of the pseudo-bishops” (Zurich Letters, i. 29). May 22nd, Jewel to Bullinger: “Religion is again placed on the same footing on which it stood in King Edward’s time; to which event I doubt not but that your own letters and those of your republic have powerfully contributed” (Zurich Letters, i. 33). May 23rd, Grindal to Conrad Hubert: “But now at last, by the blessing of God, during the prorogation of Parliament, there has been published a proclamation to banish the Pope and his jurisdiction altogether, and to restore religion to that form which we had in the time of Edward VI.” (Zurich Letters, ii. 19). Dr. Gee seems to beg an important historical question when he says that these letters must have been written before the writers knew that the Prayer-Book had been actually altered in more than the three points mentioned in the Act of Uniformity. Grindal, writing again to Hubert on July 14th, when he must have known everything, says: “The state of our Church (to come to that subject) is pretty much the same as when I last wrote to you, except only that what had heretofore been settled by proclamations and laws with respect to the reformation of the churches is now daily being carried into effect.” Cf. Gee’s Elizabethan Prayer-Book, etc. p. 104 n., for the actual differences between the Edwardine Book of 1552 and the Elizabethan Book of 1559. [565] Cambridge Modern History, ii, 570. [566] The rubric explaining kneeling at the communion had not the authority of Parliament, but only of the Privy Council, and was not included. The rubric of 1552 regarding ornaments, which had the authority of Parliament and was re-enacted by the Act of Uniformity of 1559, was: “And here is to be noted that the minister at the time of communion, and at all other times in his ministration, shall use neither alb, vestment, nor cope; but being archbishop or bishop, he shall have and wear a rochet: and being priest or deacon, he shall have and wear a surplice only.”
- 64. This is thereal ornaments rubric of the Elizabethan settlement, and appears to be such in the use and wont of the Church of England from 1559 to 1566, save that copes were used occasionally. The proviso in the Act of Uniformity (1559) was: “Such ornaments of the Church and of the ministers thereof shall be retained and be in use as was in this Church of England by authority of Parliament in the second year of the reign of King Edward VI., until other order shall be therein taken by the authority of the Queen’s Majesty, with the advice of her commissioners appointed and authorised under the Great Seal of England for causes ecclesiastical, or of the metropolitan of this realm.” The ornaments in use in the second year of Edward VI. are stated in the rubrics of the first Prayer-Book of King Edward (1549): “Upon the day, and at the time appointed for the ministration of the Holy Communion, the Priest that shall execute the holy ministry shall put upon him the vesture appointed for that ministration, that is to say: a white Albe plain, with a vestment or Cope. And where there be many Priests or Deacons, there so many shall be ready to help the Priest in the ministration as shall be requisite: and shall have upon them likewise the vestures appointed for their ministry, that is to say, Albes with tunicles.” At the end there is another rubric: “Upon Wednesdays and Fridays, the English Litany shall be said or sung in all places after such form as is appointed by the King’s Majesty’s Injunctions; or as is or shall be otherwise appointed by His Highness. And though there be none to communicate with the Priest, yet these days (after the Litany ended) the Priest shall put upon him a plain Albe or surplice, with a cope, and say all things at the Altar appointed to be said at the celebration of the Lord’s Supper, until after the offertory.” [567] Parker’s Correspondence, p. 65. [568] The rubric is: “And here it is to be noted that the minister at the time of communion and at all other times in his ministrations, shall use such ornaments in the church as were in use by authority of Parliament in the second year of the reign of King Edward VI., according to the Act of Parliament set in the beginning of this Book.”
- 65. [569] Dr. Gee(Elizabethan Ornaments, etc. p. 131) thinks that there can be no reasonable doubt that the rubric was recorded on the authority of the Privy Council. “The Privy Council had certainly inserted the Black Rubric in 1552, as their published Acts attest, but all the records of the Privy Council from 13th May 1559 until 28th May 1562 have disappeared.” The precedent cited is scarcely a parallel case. The Black Rubric was an explanation; the Rubric of 1559 is almost a contradiction in terms of the Act which restores the Prayer-Book of 1552. If I may venture to express an opinion, it seems to me most likely that the rubric was added by the Queen herself, and that she inserted it in order to be able to “hedge.” It is too often forgotten that the danger which overshadowed the earlier years of Elizabeth was the issue of a papal Bull proclaiming her a heretic and a bastard, and inviting Henry II. of France to undertake its execution. The Emperor would never permit such a Bull if Elizabeth could show reasonable pretext that she and her kingdom held by the Lutheran type of Protestantism. An excommunication pronounced in such a case would have invalidated his own position, which he owed to the votes of Lutheran Electors. In the middle of the sixteenth century the difference between the different sections of Christianity was always estimated in the popular mind by differences in public worship, and especially in the celebration of the Lord’s Supper. All over Germany the Protestant was distinguished from the Romanist by the fact that he partook of the communion in both “kinds.” Elizabeth had definitely ranged herself on the Protestant side from Easter Day 1559; and a more or less ornate ritual could never explain away the significance of this fact. The great difference between the Lutherans and the Calvinists to the popular mind was that the former retained and the latter discarded most of the old ceremonial. Luther says expressly: “Da lassen wyr die Messgewand, altar, liechter noch bleyben” (Daniel, Codex Liturgicus Ecclesiæ, Lutheranæ, p. 105); and crosses, vestments, lights, and an altar appear in regular Lutheran fashion whenever the Queen wished to place herself and her land under the shield of the Augsburg Peace. This rubric was a remarkably good card to play in the diplomatic game. [570] XXXth Injunction of 1559: “Item, Her Majesty being desirous to have the prelacy and clergy of this realm to be had as well in outward reverence, as otherwise regarded for the worthiness of their ministries, and thinking it necessary to have them known to the people in all places and assemblies, both in the church and without, and thereby to receive the honour and estimation due to the special messengers and ministers of Almighty God, wills and commands that all archbishops and bishops, and all other that be called or admitted to preaching or ministry of the sacraments, or that be admitted into any vocation ecclesiastical, or into any society of learning in either of the Universities or elsewhere, shall use and wear such seemly habits, garments, and such square caps as were most commonly and orderly received in the latter year of the reign of King Edward VI.; not meaning thereby to attribute any holiness or special worthiness to the said garments, but as St. Paul writeth: ‘Omnia decenter et secundum ordinem fiant’ (1
- 66. Cor. xiv. cap.).”Cf. Gee’s Elizabethan Prayer Booke and Ornaments (London, 1902); Tomlinson, The Prayer Book, Articles and Homilies (London, 1897); Parker, The Ornaments Rubric (Oxford, 1881). [571] The Advertisements are printed in Gee and Hardy; Documents, etc. p. 467; the Injunctions, at p. 417. [572] Copes were used in the cathedrals and sometimes in collegiate churches in the years between 1559 and 1566, when it was desired to add some magnificence to the service; but it ought to be remembered that the cope was never a sacrificial vestment. It was originally the cappa of the earlier Middle Ages—the mediæval greatcoat. Large churches were cold places, the clergy naturally wore their greatcoats when officiating, and the homely garment grew in magnificence. It never had a doctrinal significance like the chasuble or casula. [573] Calendar of State Papers, Spanish, 1558-67, p. 89. [574] Machyn’s Diary (Camden Society, London, 1844), p. 108. [575] Peacock’s Church Furniture, p. 87. [576] Calendar of State Papers, Spanish, 1558-67, p. 105: “The crucifixes and vestments that were burnt a month ago publicly are now set up again in the royal chapel, as they soon will be all over the kingdom, unless, which God forbid, there is another change next week. They are doing it out of sheer fear to pacify the Catholics; but as forced favours are no sign of affection, they often do more harm than good.” Cf. Zurich Letters, i. 63, etc. [577] Calendar of Letters and State Papers relating to English Affairs, preserved principally in the Archives of Simancas, i. pp. 76, 79. [578] Calendar of State Papers, Domestic Series, Edward VI., Mary, Elizabeth, i. 130. [579] The Injunctions are printed in Gee and Hardy, Documents, etc. p. 417. [580] Calendar of State Papers, Domestic Series, of the Reigns of Edward VI., Mary, and Elizabeth, i. pp. 180, 183, 187. [581] For the history of these Articles, see Hardwick, A History of the Articles of Religion; to which is added a Series of Documents from A.D. 1536 to A.D. 1615, etc. (Cambridge, 1859). [582] Calendar of Letters and State Papers relating to English Affairs, preserved principally in the Archives of Simancas, i. 190. [583] The Consensus Tigurinus (1549) dates the disappearance. [584] The Zurich Letters, 1558-79, First Series (Parker Society, Cambridge, 1842), pp. 123, 127, 135, 100, 139. Bishop Jewel, writing to Peter Martyr (p. 100), says: “As to matters of doctrine, we have pared everything away to the very quick, and
- 67. do not differfrom your doctrine by a nail’s breadth” (Feb. 7th, 1562); and Bishop Horn, writing to Bullinger (Dec. 13th, 1563, i.e. after the Queen’s alterations), says,: “We have throughout England the same ecclesiastical doctrine as yourselves” (ibid. p. 135). [585] The deleted clause was: “Christus in cœlum ascendens, corpori suo immortalitatem dedit, naturam non abstulit, humanæ enim naturæ veritatem (juxta Scripturas), perpetuo retinet, quam uno et definito loco esse, et non in multa, vel omnia simul loca diffundi oportet. Quum igitur Christus in cœlum sublatus, ibi usque ad finem seculi permansurus, atque inde, non aliunde (ut loquitur Augustinus) venturus sit, ad judicandum vivos et mortos, non debet quisquam fidelium, et carnis eius, et sanguinis, realem et corporealem (ut loquuntur) presentiam in Eucharistia vel credere, vel profiteri.” [586] “Cette reine est extremement sage, et a des yeux terribles.” Calendar of State Papers, Domestic Series, of the Reign of Elizabeth, 1595-97, p. xxi. [587] Calendar of Letters and State Papers relating to English Affairs, preserved principally in the Archives of Simancas, i. 61, 62. [588] Calendar of State Papers, Venetian, 1558-80, p. 449. [589] The Zurich Letters, etc., First Series, p. 91. [590] The Zurich Letters, etc., First Series, p. 74; cf. 55, 63, 64, 66, 68, 100, 129, 135. Bishop Jewel called clerical dress the “relics of the Amorites” (p. 52), and wished that he could get rid of the surplice (p. 100); and “the little silver cross” in the Queen’s chapel was to him an ill-omened thing (p. 55); cf. Strype, Annals, etc. I. i. 260. [591] Annals, etc. I. ii. 562. [592] The Advertisements of Archbishop Parker, issued and enforced on the authority of the Primate, to which the royal imprimatur was more than once refused, may be looked on as an exception. For these rules, meant to control the Church in the vestiarian controversy, see Gee and Hardy, Documents, etc. p. 467; and for the vexed question of their authority, Moore, History of the Reformation, p. 266. [593] Maitland, Cambridge Modern History, ii. 569 ff. [594] Calendar of State Papers, Domestic Series, of the Reigns of Edward VI., Mary, and Elizabeth, 1547-80, p. 159. [595] Calendar of State Papers, Domestic Series, etc. p. 247. [596] Ibid. p. 177; Calendar of Letters and State Papers relating to English Affairs, preserved principally in the Archives of Simancas, i. 77, 118, 119.
- 68. [597] The storyof Francis Yaxley, Mary’s agent, of his dealings with Philip II., of Philip’s subsidy to Scotland of 20,000 crowns, of its loss by shipwreck, and how the money was claimed as treasure-trove by the Duke of Northumberland, Roman Catholic and a pledged supporter of Mary as he was, may be traced in the Calendar of Letters and State Papers relating to English Affairs, preserved principally in the Archives of Simancas, pp. lix, 499, 506, 516, 523, 546, 557; and how the Pope also gave aid in money, p. 559. [598] For example, the Nikolsburger Articles say: “Cristus sei in der erbsunden entphangen; Cristus sei nit Got sunder ein prophet, dem das gesprech oder wort Gottes bevollen worden” (Cornelius, Geschichte des Münsterischen Aufruhrs, ii. 279, 280). [599] Servede was born in 1511, in the small town of Tudela, which then belonged to Aragon. He came from an ancient family of jurists, and was at first destined to the profession of law. His family came originally from the township of Villanova, which probably accounts for the fact that Servede sometimes assumed that name. He was in correspondence with Oecolampadius (Heusgen) in 1530; and from the former’s letters to and about Servede, it is evident that the young Spaniard was then fully persuaded about his anti-Trinitarian opinions. No publisher in Basel would print his book, and he travelled to Strassburg. When his first theological book became known, its sale was generally interdicted by the secular authorities. His great book, which contains his whole theological thinking, was published in 1553 without name of place or author. Its full title is: Christianismi Restitutio, Totius ecclesiæ apostolicæ ad sua limina vocatio, in integrum restituta cognitione Dei, fidei Christi, justificationis nostræ, regenerationis baptisimi et cœnæ domini manducationis, Restituto denique nobis regno cœlesti, Babylonis impiæ captivitate soluta, et Antichristo cum suis penitus destructo. He entered into correspondence with Calvin, offered to come to Geneva to explain his position; but the Reformer plainly indicated that he had no time to bestow upon him. The account of his trial, condemnation, and burning at Geneva is to be found in the Corpus Reformatorum, xxxvi. 720 ff. The sentence is found on p. 825: “Icy est este parle du proces de Michiel Servet prisonnier et veu le sommairre dycelluy, le raport de ceux esquelz lon a consulte et considere les grands erreurs et blaffemes—est este arreste Il soit condampne a estre mene en Champel et la estre brusle tout vyfz et soit exequente a demain et ses livres brusles.” This trial and execution is the one black blot on the character of Calvin. He was by no means omnipotent in Geneva at the time; but he thoroughly approved of what was done, and had expressed the opinion that if Servede came to Geneva, he would not leave it alive. “Nam si venerit modo valeat mea auctoritas, virum exire nunquam patiar” (Corpus Ref. xi. 283). [600] Ritschl, A critical History of the Christian Doctrine of Justification and Reconciliation (Eng. trans., Edin. 1872), p. 295.
- 69. [601] “Circa annum1546 instituerat (Lælius Socinus) cum sociis suis iisdem Italis, quorum numerus quadragenarium excedebat, in Veneta ditione (apud Vincentiam) collegia colloquiaque de religione, in quibus potissimum dogmata vulgaria de Trinitate ac Christi Satisfactione hisque similia in dubium revocabant” (Bibl. Antit. p. 19—I have taken the quotation from Fock, Der Socinianismus nach seiner Stellung in der Gesammtentwickelung des christlichen Geistes, etc., Kiel, 1847, i. 132). [602] Sources: Magna Bibliotheca Veterum Patrum (Coloniæ Agrippinæ, 1618), xiii. 299-307; Sebastian Franck, Chronica, Zeitbuch und Geschichtbibel (Augsburg, 1565), pt. iii.; Hans Denck, Von der waren Lieb, etc. (1527—republished by the Menonitische Verlagsbuchhandlung, Elkhart, Indiana, U.S.A.); Bouterwek, Zur Literatur und Geschichte der Wiedertäufer (Bonn, 1864—gives extracts from the rarer Anabaptist writings such as the works of Hübmaier); Ausbund etlicher schöner christlicher geseng, etc. (1583); Liliencron, “Zur Liederdichtung der Wiedertäufer” (in the Abhandlungen der könig. Bair. Akad. der Wissenschaften Philosophische Klasse, 1878); von Zezschwitz, Die Katechismen der Waldenser und Bömischen Bruder (Erlangen, 1863); Beck, Geschichts-Bücher der Wiedertäufer in Österreich-Ungarn, 1526 bis 1785 (Vienna, 1883), printed in the Fontes Rer. Austr. Diplom. et Acta, xliii.; Kessler, Sabbata, ed. by Egli and Schoch (St. Gall, 1902); Bullinger, Der Wiedertäuferen Ursprung, Secten, etc. (Zurich, 1560); Egli, Actensammlung zur Geschichte der Züricher Reformation (Zurich, 1879), Die Züricher Wiedertäufer (Zurich, 1878); Leopold Dickius, Adversus impios Anabaptistarum errores (1533); Cornelius, Berichte der Augenzeugen über das Münsterische Wiedertäuferreich, forming the 2nd vol. of the Geschichtsquellen des Bisthums Münster (Münster, 1853) and the Beilage in his Geschichte des Münsterischen Aufruhrs (Leipzig, 1855); Detmer’s edition of Kerssenbroch, Anabaptistici furoris Monasterium inclitam Westphaliæ metropolim evertentis historica, narratio, forming vols. v. and vi. of the Geschichtsquellen des Bisthums Münster (Münster, 1899, 1900); Chroniken der deutschen Städte, Nürnberg Chronik, vols. i. and iv. Later Books: Keller, Geschichte der Wiedertäufer und ihres Reichs zu Münster (Münster, 1880), Ein Apostel der Wiedertäufer; Hans Denck (Leipzig, 1882), and Die Reformation und die älteren Reformparteien (Leipzig, 1885—Keller is apt to make inferences beyond his facts); Heath, Anabaptism, from its rise at Zwickau to its fall at Münster, 1521-1536 (London, 1895); Belfort Bax, Rise and Fall of the Anabaptists (London, 1903); Rörich, “Die Gottesfreunde und die Winkeler am Oberrhein” (in Zeitschrift für hist. Theol. i. 118 ff., 1840); Zur Geschichte der strassburgischen Wiedertäufer (Zeitschrift für hist. Theol. xxx. 1860); S. B. ten Cate, Geschiedenis der doopgezinden in Groningen, etc., 2 vols. (Leeuwarden, 1843); Geschiedenis der doopgezinden in Friesland (Leeuwarden, 1839); Geschiedenis der doopgezinden in Holland en Guelderland, 2 vols. (Amsterdam, 1847); Tileman van Braght, Het bloedig Toenecl of Martclaars Spiegel der
- 70. doopgesinde (Amsterdam, 1685);E. B. Underhill, Martyrology of the Churches of Christ commonly called Baptist (translated from Van Braght); H. S. Burrage, A History of the Anabaptists in Switzerland (founded on Egli’s researches, Philadelphia, 1881); Newman, A History of Anti-Pedobaptism (Philadelphia, 1897); Detmer, Bilder aus den religiösen und sozialen Unruhen in Münster während des 16 Jahrhunderts: i. Johann von Leiden (Münster, 1903), ii. Bernhard Rothmann (1904), iii. Ueber die Auffassung von der Ehe und die Durchführung der Vielweiberei in Münster während der Täuferherrschaft (1904); Heath, Contemporary Review, lix. 389 (“The Anabaptists and their English Descendants”), lxii. 880 (“Hans Denck the Baptist”), lxvii. 578 (Early Anabaptism, what it meant, and what we owe to it), lxx. 247 (“Living in Community—a sketch of Moravian Anabaptism”), 541 (“The Archetype of the Pilgrim’s Progress”), lxxii. 105 (“The Archetype of the Holy War”). [603] The difference in treatment may be seen at a glance by comparing the articles on Anabaptism in the second (1877) and in the third (1896) edition of Herzog’s Realencyclopädie für protestantische Theologie und Kirche. Some eminent historians, however, still cling to old ideas; for example, Edward Armstrong, The Emperor Charles V. (London, 1902), who justifies the treatment his hero meted out to the Anabaptists—roasting them to death before slow fires— by saying that “whenever they momentarily gained the upper hand, they applied the practical methods of modern Anarchism or Nihilism to the professed principles of Communism” (ii. 342). No one who has examined the original sources could have penned such a sentence. [604] Magna Bibliotheca Veterum Patrum (Coloniæ Agrippinæ, 1618), xiii. 299, 300, 307 (the Summa of Raiverus Sacchonus). Cf. i. 152. [605] These are the dates at which town chronicles incidentally show that such communities existed, not the dates of their origin. [606] Vedder, Balthasar Hübmaier (New York, 1905). [607] Liliencron, “Zur Liederdichtung der Wiedertäufer,” in the Transactions of the Königl. Bair. Akad. der Wissenschaften, Philosophisch-historische Klasse, 1877. [608] Chronica (Augsburg edition, 1565), f. 164. [609] Der Wiedertäuferen Ursprung, Furgang, Secien, etc. (Zurich, 1560). [610] Chronica (3 pts., Strassburg, 1531). [611] Sabbata (ed. by Egli and Schoch, St. Gall, 1902). [612] C. A. Cornelius, Geschichte des Münsterischen Aufruhrs (Leipzig, 1855), ii. 49. [613] Ibid. ii. 49.
- 71. [614] Magna BibliothecaVeterum Patrum (Coloniæ Agrippinæ, 1618), Rainerii Socchoni, Summa, c. vii. [615] Egli, Die Züricher Wiedertäufer (Zurich, 1878), p. 96. [616] Folio 158b of the Augsburg edition of 1565. [617] The Swiss Anabaptists have been selected because we have very full contemporary documentary evidence in their case. Cf. Egli, Actensammlung zur Geschicht der Züricher Reformation (Zurich, 1879); Die Zuricher Wiedertäufer (Zurich, 1878); Die St. Gallen Wiedertäufer (Zurich). The documentary evidence given in Egli’s works has been condensed and summarised by H. S. Burrage, A History of the Anabaptists in Switzerland (Philadelphia, 1881). [618] The scene is described in Beck, Die Geschichts-Bücher der Wiedertäufer in Österreich-Ungarn von 1526 bis 1785 (Vienna, 1883). [619] The history of the persecution in the Tyrol is to be found in J. Loserth, Anabaptismus in Tirol; and in Kirchmayr, Denkwürdigkeiten seiner Zeit, 1519-53, pt. i. in Fontes Rerum Austriacarum, i. 417-534. [620] Cornelius, Geschichte des Münsterischen Aufruhrs (Leipzig, 1855), ii. 58. [621] The disease was known as the English plague or the sweating sickness. It is thus described by Hecker (Epidemics of the Middle Ages, p. 181): “It was violent inflammatory fever, which, after a short rigour, prostrated the powers as with a blow; and amidst painful oppression at the stomach, headache, and lethargic stupor, suffused the whole body with fœtid perspiration. All this took place within the course of a few hours, and the crisis was always over within the space of a day and a night. The internal heat that the patient suffered was intolerable, yet every refrigerant was death.” [622] Rothmann was born at Stadtlohn, and received the rudiments of education in the village school there; a relation sent him to the Gymnasium at Münster; he studied afterwards at Mainz, where he received the degree of M.A.; he was made chaplain in the St. Maurice church at Münster about 1525. [623] His confession of faith, published in Latin and German in 1532, shows this. I know it only by the summary in Detmer (Bernhard Rothmann, Münster, 1904, pp. 41 f.). Detmer says that he knows of only one printed copy, which is in the University Library at Münster. [624] Bernardin Knipperdolling or Knipperdollinck (both forms are found) was a wealthy cloth merchant, an able and fervent speaker, a man of strong convictions, who had early espoused the people’s cause, and had become the trusted leader of the democracy of Münster.
- 72. [625] The detailsof this Disputation have been published by Detmer in the Monatshefte der Commenius-Gesellschaft (Berlin, 1900), ix. 273 ff. [626] Cf., above, ii. 235 ff. [627] Meister Heinrich Gresbeck’s Bericht von der Wiedertaufe in Münster, p. 20 (edited by Cornelius for Die Geschichtsquellen des Bisthums Münster, vol. ii., Münster, 1853). [628] Cf. Die Münsterische Apologie, printed by Cornelius in his Berichte der Augenzeugen über das münsterische Wiedertäuferreich, p. 457 (Geschichtsquellen des Bisthums Münster, vol. ii.). [629] By far the best and most impartial discussion of the institution of polygamy in Münster—one that is based on the very widest examination of contemporary documentary evidence—is that of Dr. Detmer, Ueber die Auffassung von der Ehe und die Durchführung der Vielweiberei in Münster während der Täuferherrschaft (Münster, 1904). It forms the third of his Bilder aus den religiösen und sozialen Unruhen in Münster während des 16. Jahrhunderts. [630] The tract is to be found in Cornelius, Berichte der Augenzeugen über das münsterische Wiedertäuferreich, which forms the second volume of Die Geschichtsquellen des Bisthums Münster (pp. 445 ff.). [631] “Die ehe, sagen wir und halten mit der Schrift, das sie ist eins mans und weips vorgaderong und vorpflichtong in dem Herrn ... Got hot den menchen von anfanck geschaffen, ein man und weip hat Er sie geschaffen, di peide in den heiligen estant (ehestat) voreiniget, dos di peide zwo sellen und ein fleische solen sein. Und mage also kein mensche scheiden selche voreinigong” (pp. 457, 458). [632] The Restitution, written by Rothmann and Kloprys in conjunction with Jan of Leyden and the elders, is published in Bouterwek, Literatur und Geschichte der Wiedertäufer; marriage and polygamy are treated in sections 14-16. [633] Jan Bockelson, commonly called Jan van Leyden, was the illegitimate son of a village magistrate, and was born near Leyden in 1510. After a brief time of education at a village school he was apprenticed to a tailor, and in his leisure hours diligently educated himself. He travelled more widely than artisans usually did during their year of wandering—visiting England as well as most parts of Flanders. On his return home he married the widow of a shipmaster, and started business as a merchant. He was a prominent member of the literary “gilds” of his town, and had a local fame as a poet and an actor. His conversion through Jan Matthys changed his whole life; there is not the slightest reason to suppose that he was not an earnest and honest adherent of the Anabaptist doctrines as taught by Matthys. He is described as strikingly handsome, with a fine sonorous voice. He had remarkable powers of organisation. His whole brief life reveals him to be a
- 73. very remarkable man.He was barely twenty-five when he was tortured to death by the Bishop of Münster after the capture of the town. [634] Sources: Bibliotheca Fratrum Polonorum (Amsterdam, 1656) i. ii. Racovian Catechism (London, 1818). Later Books: Fock, Der Socinianismus nach seiner Stellung in der Gesammtentwickelung des christlichen Geistes, nach seinem historischen Verlauf und nach seinem Lehrbegriff dargestellt (Kiel, 1847); A. Ritschl, Jahrbücher f. deutsche Theologie, xiii. 268 ff., 283 ff.; A critical History of the Christian Doctrine of Justification and Reconciliation (Edinburgh, 1872); Dilthey, Archiv f. Geschichte d. Philos. vi.; Harnack, History of Dogma, vii. 118 ff. (London, 1899). [635] Pp. 397 ff. [636] Cf. i. 426 ff. [637] Harnack, History of Dogma, vii. 167. [638] Cf. p. 427. [639] Cf. i. 461. [640] Erasmus, Opera Omnia, iv. 465. [641] A very full analysis of the contents of the Racovian Catechism is given in Harnack’s History of Dogma, vii. 137 ff., also in Fock, Der Socinianismus, etc. ii. A. Ritschl has shown that the Unitarianism of the Socinians is simply the legitimate conclusion from their theory of the nature of God and of the work of Christ, in his two essays in the Jahrbücher f. deutsche Theol. xiii, 268 ff., 283 ff. [642] Sources: Laemmer, Monumenta Vaticana historiam ecclesiasticam seculi 16 illustrantia (Freiburg i. B. 1861); Weiss, Papiers d’État du Cardinal Perronet de Granvelle (in the Collection des documents inédits de l’Histoire de France, 1835- 49); Fiedler, Relationen Venetianischer Botschaften über Deutschland und Oesterreich im 16ten Jahrhunderte (in the Fontes Rerum Austriacarum, Diplomatica et Acta, xxx., Vienna, 1870); Friedenburg, Nuntiaturberichte aus Deutschland, 1533-39 (Gotha, 1892-93); Carteggio di Vittoria Colonna (Rome, 1889). Later Books: Maurenbrecher, Geschichte der katholischen Reformation (Nördlingen, 1880—only one volume published, which ends with 1534); also Karl V. und die deutschen Protestanten (Düsseldorf, 1865); Ranke, Die römischen Päpste, ihre Kirche und ihr Staat im sechszehnten und siebzehenten Jahrhundert; Gothein, Ignatius von Loyola und die Gegenreformation (Halle, 1895); Philippson, La Contre-Revolution religieuse du 16e siècle (Brussels, 1884); Ward, The Counter- Reformation (London, 1889); Dupin, Histoire de l’Église du 16e siècle (Paris, 1701- 13); Jerrold, Vittoria Colonna (London, 1906).
- 74. [643] Cf. ARelation ... of the Island of England ... about the year 1500 (Camden Society, London, 1847), pp. 34-36, 86-89. [644] Cf. i. 36. [645] This had been protested against for a century and a half, not merely by individual moralists, but by such conventions of notables as the English Parliament; cf. Rolls of Parliament, ii. 313-14; Item, “prie la Communeque comme autre foithz au Parlement tenuz a Wyncestre, supplie y fuist par la Commune de remedie de ce que les Prelatz et Ordinares de Seint Esglise pristrent sommes pecuniers de gentz de Seint Esglise et autres pur redemption de lour pecche de jour en jour, et an en an, de ce que ils tiendrent overtement lours concubines; et pur autres pecches et offenses a eux surmys, dount peyne pecunier ne serroit pris de droit: Quele chose est cause, meintenance et norisement de lour pecche, en overte desclandre, et mal ensample de tut la Commune; quele chose issint continue nient duement puny, est desesploit an Roi et a tout le Roialme. Qe pleise a nostre Seigneur le Roi ent ordeiner que touz tiels redemptions soient de tut ousteiz; et que si nul viegne encontre ceste Ordeinance, que le prenour encourge la somme del double issint pris devers la Roi et cely que le paie eit mesme la peyne.” [646] Cf. i. 166, 213. [647] Cf. vol. i. 140, 141, 378; vol. ii. [648] Letters and Papers, Foreign and Domestic, of the Reign of Henry VIII., iv., Preface, p. 485. Cf. Brown, Fasciculus rerum expectendarum et fugiendarum (1690), pp. 19, 20, for the speech of an English Bishop at Rome (Nov. 27th, 1425), saying that if the Curia does not speedily undertake the work of Reformation, the secular powers must interfere. [649] Lea, Chapters from the Religious History of Spain (Philadelphia, 1890); Prescott, Ferdinand and Isabella (London, 1887); V. de la Fuente, Historia eclesiastica en Espana (Madrid, 1873, etc.); Menendezy Palayo, Los Heterodoxos Espanoles (Madrid, 1880); Hefele, The Cardinal Ximenes (London, 1860); Paul Rousselot, Les Mystiques Espagnols (Paris, 1867). [650] Cf. paper read by Charles V. to the Estates of Germany at Worms—Wrede, Deutsche Reichstagsakten unter Kaiser Karl V. (Gotha, 1896) ii. 595. [651] “Is Cæsaris consanguineus, legatus missus a Wormacia, festinando ad Hispanos pro sedando quodam tumultu. Is in profesto vigiliæ natalicii dominici superveniens eques, cum ministris, biduo manens integro et tribus noctibus, mihi multum loquebatur de causa Lutherana, quæ magna ex parte arridebat viro bono et docto, præter librum de captivitate Babel, quem legerat Wormatiæ cum mœrore et displicentia, quem ego nondum videram.” Riggenbach, Das Chronikon des Konrad Pellikan, p. 77 (Basel, 1877).
- 75. [652] Carvajal’s speechand Egidio’s memoir are given in Höfler, “Analecten z. Geschich. Deutschlands und Italiens” (Abhandlungen der Münch. Akad. IV. iii. 57- 89). [653] An indult can be best explained by an example: according to the Council of Bourges (1438), the selection of French Bishops was left exclusively in the hands of the Chapters of the Cathedrals; but Pope Eugenius IV. permitted Charles VII. the right to appoint to several specified bishoprics; such a papal grant was called an indult. [654] Cf. vol. i. 12 f. [655] Sources: Contarini, Opera (Paris, 1571); Correspondenz Contarinis, ed. by L. Pastor (1880); Cortese, Epistolarum familiarum liber (Venice, 1573); Ghiberti, Opera (Verona, 1740); Sadoleto, Epistolarum libri sexdecim (Lyons, 1560); Pole, Epistolæ, et aliorum ad ipsum (Brescia, 1744-57), Carteggio di Vittoria Colonna (Turin, 1889); Vergerio, Briefwechsel (edited for the Bibliothek des literarischen Vercius, Stuttgart, 1875). Later Books: Jacob Burckhardt, The Civilisation of the Period of the Renaissance (Eng. trans., London, 1892); Symonds, Renaissance in Italy. The Catholic Reaction (London, 1886); Cantù, Gli Eretici d’Italia (Turin, 1865-67); Braun, Cardinal Gasparo Contarini (1903); Dittrich, Gasparo Contarini (Braunsberg, 1883); Duruy, Le Cardinal Carlo Caruffa (Paris, 1882); Gothein, Ignatius Loyola und die Geyenreformation, pp. 77-207 (Halle, 1895); v. Reumont, Vittoria Colonna (Freiburg i. B. 1881). [656] Mediæval songs tell us that this hatred of the peasantry is much older than the Renaissance: “Si quis scire vult naturam, Maledictam et obscuram Rusticorum genituram Infelicem et non puram Denotent sequentia,” etc. Carmina Medii Æri (Florence, 1883), p. 34; the song belongs to the thirteenth century. [657] Herminjard, Correspondance, etc. viii. 161. [658] The name went beyond the original foundation. The Jesuits were sometimes called Theatines both in Spain and in France. [659] They are to be found in Bibliotheca Maxima Pontificia (Rome, 1790), pp. 178 ff. The contents of the second letter are condensed in the phrase which occurs near the end: “in legibus voluntas non debet regula esse” (p. 183). The first letter urges the Pope to make an end of the scandals caused by the sale of
- 76. Welcome to ourwebsite – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com