There is really nothing to new here. Much of the communications work done
today which has to under go "Regulatory Agency Compliance Testing" is
written in and tested in exactly this manner. You design the system to pass
the well defined tests. The problem with this type of testing is what to
test in addition to the requirements. All that is frequently shown is that
the system responds to expected stimulus correctly. The tick is to
anticipate all possible unplanned for stimuli and test for function given
those as well as the expected ones. This is particularly interesting with a
dynamically defined system in which extensive functional modifications are
added years after the basic system was conceived. There is the additional
complication that as far as I know no one sells a completely certified
processor, one in which all possible states are defined and handled in a
recoverable fashion.
Testing in the New Age has become virtually the Holy Grail to be forever
pursued and never actually completed.
Paul N. Henning
K9PH
Director of Research and Development
Amtelco
4800 Curtin Drive
McFarland, Wisconsin 53558
www.amtelco.com
paul@amtelco.com
(608)838-4194
-----Original Message-----
From: Mark Erbaugh [mailto:mark@microenh.com]
Sent: Monday, September 13, 2004 4:14 PM
To: tentec@contesting.com
Subject: [TenTec] OT: Software Testing
> Software manufacturing is done today on a scale that is prohibitive of
> recursion testing that was possible 30 years ago. NASA is a good
> example of skipping tests in the interests of getting things out the
> door on time. Years ago, we put men on the moon using slide rules and
> pencils - today we have computers which can process billions of
> equations saving millions of man-hours but because those man-hours were
> saved (and thereby an engineer did not monitor each calculation made)
> things slip through the cracks - the level of qualitative testing is
> essentially eliminated because we rely on the computer instead of
> inspecting everything by hand. And remember, what you save in labor you
> make up for with time, and what you save in time you make up for with
labor.
I know we are getting somewhat off the topic here.
I'm also a software engineer. I'm currently reading a book on which a friend
was a contributor. The book discusses extreme programming or XP (no
relationship to Windows XP). One of the features of XP is test driven
development where the tests (called unit tests) are actually written first.
Then you write the software to pass the test. This is all done within an
automatic testing framework. You add a test to the test suite and run the
test framework. Since the software hasn't been written to pass the test, it
fails which is usually indicated by a red bar in the test framework. You
then write the code in an attempt to pass the test and run the test
framework again. Eventually you will get the software to pass the test,
getting a green bar. At that point, you add another test.
Note that the original test is still part of the test framework. If
something you add to pass a later test causes the software to fail, that
will bring back the red bar of failure. Thus you can have a pretty high
confidence level that what you added didn't break something that was already
working.
73,
Mark
_______________________________________________
TenTec mailing list
TenTec@contesting.com
http://lists.contesting.com/mailman/listinfo/tentec
_______________________________________________
TenTec mailing list
TenTec@contesting.com
http://lists.contesting.com/mailman/listinfo/tentec
|