Royal Pain

[Peter L. Peres]

On Sun, 20 Jun 2004, David Thornton wrote:

> So tell us about "Quality Assurance for Computer Software". What do you
> learn. What did you find rang true for you? What did you disagree with?

I agree with 99% of what is written in that book. I learned that it is
very important to talk to the users and look 'outside' when considering
what a product does. Perfection in the lab test will only make very few
people happy with a product. I learned that I was right to believe that
both perfection and its knowledge (!) is denied to normal mortals ;-) I
learned some ways to quantify my errors and use that information to
improve the quality of what I do, and it showed me where to look for
mistakes that *I* can find.

Imho the book lacks enough references to real life everyday problems like
the blind fish effect (you can't see the obvious mistake in front of your
eyes because you've been looking at the code for too long at a stretch -
for example), workplace ergonomics (in software engineering - as in
desktop environments - and why cute animations and 16 million colors are
likely bad for your error rate)  and the role of fatigue in error rates,
but it lacks this because it has a different, more general focus.

I think that it's a very good book and it has extensive
references (to other books and publications) that point to further
reading.

> Give us a mini review.

I will try to a little, but you really want to read this book. Try your
local technical or university library. There may be a more recent version.

In short sentences, the book treats quality assurance as a people thing,
that has very little to do with software engineering per se, and pushes
the process to a degree of abstraction where it applies to any other type
of production or thought or business process. It goes on by explaining the
problems that appear when abstract concepts and business 'data' (let's
call them white lies)  collide with the real world, using examples, and
makes a thorough pass through the types of problems that affect software
Q. . Then it delves into real techniques used for qa in software
engineering and testing, many of which have to do with things like
feedback (from the users), education (of the users and of the team), and
introducing metrics that measure error rates and densities, and shows ways
to use this data, in the form of quality programs. It also shows how to
find the 'concentrations' of errors and techniques to squash them.

The authors worked at ITT at the time they wrote this book, in
aerospace/defence related software work. The quality of the work shows
this. They say clearly that they consider the work relevant to any kind of
software (and most examples in the book are not aerospace related). The
book should be in university libraries because I think it is used in some
courses ?

To finish here is a longer quote (from Chapter 4 pp.72):

"It is in the tradition of computer software that latent defects are
called by any name but that. The usual designations are "bugs", "errors",
or more euphemistically, "software problems". Small matter. They exist,
and, indeed, are likely to continue to exist despite the efforts of
quality assurance. Software quality assurance can be instrumental in
markedly decreasing their number, but it is unrealistic to assume that
defects can be entirely eliminated. This may appear to be a surprisingly
tolerant attitude; one scarcely consonant with the historical goals of the
quality community. However, as a fact of software life, no degree of
quality control can assure that a computer program, save for the most
trivial, can ever be placed into use totally free of "bugs".

(in the next paragraph it explains that even a very simple assembly
program can have some 10^17 discrete states and that exhaustive testing is
not an available solution). The book has about 300 pages and an index.

> I have to admit , being an egg myself, I don't quite grok parts of your
> post:

What is being an egg ?

> "Ok, so his perpetuum mobile works when you're looking ;-)"
>     What do mean?

I was jokingly referring to the implication that the other book offers
proven solutions towards perfection/bug freenes (I consider bug freeness
and perfection to be unreachable ideal abstractions).

> "please respect mine"
>     Is there some way in which I disrespected you?

No I did not imply that anybody didn't. It's just a phrase. I am sorry if
I touched anybody here, and I apologize for it.

Peter
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml