Overview of Structured Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 62

with the expectation that software developers who know how to test make better
software developers. We agree with Dr. Jones' expectation and subscribe to his
statement:
“… SPRAE is general enough to provide guidance for most testing situations.” [17]
We also believe that Dr. Jones' statement intimates that the greater value of SPRAE
is in the hands of experienced software testers.
Our professional examination of SPRAE has revealed SPRAE to be as robust as
the checklists available from the three common sources of testing methods previously
mentioned. This implies a double benefi t for those software professionals and students
who invest the time and effort to learn SPRAE. The fi rst benefi t is core testing concepts
and a checklist that does deliver good testing. The second benefi t is substantially
transferable skills from testing job to testing job, regardless of the customized test-
ing checklists used by the new employer. Recall that most of the differences among
commercial testing methods are found in the development cycle terminology and mile-
stone positioning. Learn the new development life cycle and terminology and prior
testing checklist experience can be leveraged in the new development organization.
The SPRAE checklist has fi ve items. The acronym “SPRAE” is derived from
the fi rst letter of each checklist item.
S pecifi cation
P remeditation
R epeatability
A ccountability
E conomy
3.3.1 Specification
The specifi cation is a written statement of expected software behavior. This software
behavior may be visible to the end user or the system administrator or someone in
between. The intent of the testing specifi cation is to give focus to all subsequent test
planning and execution. Dr. Jones states the corollary of this principle to be “no
specifi cations, no test.” This is the pivotal concept most often misunderstood about
software testing. Dr. James A. Whittaker at the Florida Institute of Technology rein-
forces Dr. Jones' criticality of specifi cations as a prerequisite for successful testing
by continuously asking his testing students, “Why are you testing that?” [18]
3.3.2 Premeditation
Premeditation is normally expressed as written test plans, test environments, test
data, test scripts, testing schedules, and other documents that directly support the
testing effort. The actual quantity of documentation varies widely with the size
and duration of the testing project. Small, quick testing projects need only a few,