Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!apple!well!jjacobs
From: jjacobs@well.sf.ca.us (Jeffrey Jacobs)
Newsgroups: comp.software-eng
Subject: Re: Specification Tools and Code Testing
Message-ID: <20013@well.sf.ca.us>
Date: 24 Aug 90 20:10:34 GMT
References: <1990Aug13.140347.9441@nixtdc.uucp> <19578@well.sf.ca.us> <8316@fy.sei.cmu.edu>
Distribution: usa
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 64


In <8316@fy.sei.cmu.edu>, Bruce Benson writes:

> What activity does not need experienced people?  Give me some compelling
> reasons why one activity (such as test) should have more or less experienced
> people then another activity (QA, design, coding, etc).

All software engineering activities require experienced people.  However,
the general hiring requirements and patterns for testing are right at the
bottom; take a look at misc.jobs.offered or your local Sunday want ads and
see how many ads you can find for testing (or QA) requiring more than
two years of experience.

I agree that inspection and so-called "unit"/structural testing should be the
developer's responsibility.  However, this does not eliminate the
need for an independent testing organization.  a)  Programmers still
tend to be blind to their own mistakes.  b) Large systems involve
a level of complexity that cannot cost effectively tested by the
programmers, e.g. "integration testing", "systems testing", etc.  In
most cases, the programmers frequently don't even have a sufficiently
broad knowledge of the system to know where to start, nor can they
be expected to acquire such knowledge and still do any development work.

"Code working well" is only a part of building a large system.  I've seen
more than one project where all of individually tested piece "work well",
yet when put together, the whole thing falls apart.

The so-called "black team" approach still works quite well.

> Well, getting it right the first time works pretty well too.

No argument there!  But I happen to thing that the "first time" should
mean the first time it gets *executed* (or close to the first time).  This
means inspecting before testing.  And, for the individual programmmer,
it means *desk checking* the code before running their unit (or
structural) tests.  I also strongly advocate an independent review of the
code prior to execution.   In the ideal environment, these independent
reviews would be informal and an ingrained part of the "culture" of
the company.

It also means much more time spent in design and planning.

> Most code written is correct.  The trick is to increase this percentage.

Make up your mind! :-)  Frankly, I'm afraid my experience forces me to
disagree.  Most code written is not correct.  Even if the system doesn't
crash or corrupt data, if it isn't functionally correct, then the code
isn't correct.  But I've seen far too much code that did crash/corrupt
data/return bad results to come close to accepting the word "most".

> The entire software process must work well...

> Independent test did the functional test, and we argued a lot over if the
> function was implemented correctly...

This is indicative of a major flaw in the process!!!  If everybody
is arguing a lot over the functionality of the system then the requirements
and analysis were obviously done poorly!!!


Jeffrey M. Jacobs
ConsArt Systems Inc, Technology & Management Consulting
P.O. Box 3016, Manhattan Beach, CA 90266
voice: (213)376-3802, E-Mail: 76702.456@COMPUSERVE.COM