BKY2KSWT.RVW   990313

"Year 2000 Software Testing", William Perry, 1999, 0-471-31428-5
%A   William Perry
%C   5353 Dundas Street West, 4th Floor, Etobicoke, ON   M9B 6H8
%D   1999
%G   0-471-31428-5
%I   John Wiley & Sons, Inc.
%O   416-236-4433 fax: 416-236-4448 rlangloi@wiley.com
%P   413 p.
%T   "Year 2000 Software Testing"

In the introduction, the stated audience tends towards those with
professional training and even certification in the field of software
testing.  On the other hand, at least one target group (lawyers) are
unlikely to have either direct experience or even conceptual knowledge
of the testing area.

Chapter one says that you should have a plan, although it emphasizes
the importance of testing at each phase of the project.  Some
workpapers are provided to help with planning, but, along with much of
the other material, these incline to the sensational or
scaremongering, rather than the practical.  The testing strategies
outlined in chapter two are very generic, and do not indicate a real
awareness of Y2K issues.  For example, interoperability is buried at
the bottom of a list of test factors, and given only minor status. 
The same is true of chapter three.

Although chapter four is supposed to introduce the nine step testing
process, it reads more like a grab bag of management generalities on
projects and drafting teams.  Chapter five starts the process with a
verification of the year 2000 assessment done in planning the project. 
The workpapers prepared for this step have more potential value than
those presented previously, but the text assumes a kind of "cart
before the horse" stance: it is simply accepted that the tester is the
one driving the project.  There are lots of forms and lots of
promotion of testing in chapter six, but little solid direction for
actually planning the testing.  Determining supplier compliance, in
chapter seven, is basically a duplication of step 2, and of the
suppliers work, as well.  With minor alterations, step four, in
chapter eight, is a copy of step one, in chapter five.  Chapter nine
outlines the formal methods review of software undertaken before it is
actually run.  Again, most of the content is on structure and
reporting, rather than the actual review work itself.  The
decomposition of requirements into actual test procedures has some
useful pointers in chapter ten.  The material on acceptance testing,
in chapter eleven, points out how many aspects need to be assessed.  I
was rather astonished to find that reporting was left until chapter
twelve: presumably reports need to be made at every step of the way. 
Implementation monitoring and change control is discussed in chapter
thirteen.

Given an audience experienced in testing methods, the continual
promotion of testing is redundant.  Given an audience not familiar
with testing, the lack of background greatly reduces the value of the
text.  Almost none of the content deals with testing issues directly
or specifically affected by the Y2K problem.  Indeed, given the
urgency of the situation, one would expect some discussion of triage
or practical shortcuts rather than unrealistic "best practices." 
There are, as always, some useful pointers buried in the book, but at
this juncture it should only be considered a final check for those who
have the luxury of extra time.

copyright Robert M. Slade, 1999   BKY2KSWT.RVW   990313