SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Tue, 20 Apr 2004 08:00:51 PDT7
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: May SIG meeting

Content Type: text/plain

Zdenek Jizba has offered to demonstrate his means of testing
his APL programs. I have offered him a suitable machine to
present his process in our May meeting.

In the SDP testing is the fifth stage. In theory, in software
project management and scheduling, commonly we allocated
time for testing equal to twice that for the four stages
preceding it, i.e. testing gets half the total time. In practice
due to the first four stages, particularly construction,
exceeding their estimates and a general unwillingness to
extend the total time, testing gets short changed.

We can decompose testing into a set of test cases, the test
cases themselves into a set of test scripts, and the test scripts
individually into required test data. Ideally each test case has
one test script with data for one test. In such an ideal world
we could in theory perform all test cases in parallel instead of
sequentially. That would reduce the total test time required
for a single comprehensive test to that of time for the longest
test case.

Each test case assumes a set environment, i.e. an initial state,
for each test case. Parallel execution then requires a set of
environments equal to the number of test cases. Sequential
execution requires setting or resetting the environment for
each test case. In either instance you have an initial
environment into which you introduce the test data values,
execute the test, and a resulting environment of changed
data values. The test case itself requires that both initial
values and test results be known prior to execution of the
test, i.e. that this set of input values produces this set of
outputs, in order for verification of test results to occur.

Notice that you manually have to determine the test cases,
write the test scripts, write the initial test data values, and
write the resulting data values. You can begin to write test
cases for the specifications, providing they are complete
enough with respect to the programs, or you can wait until
you have the programs. Depending on when you can start
such writing determines the amount of overlap of test case
preparation with respect to the first four stages.

Now during software development itself changes occur,
planned changes to specifications and changes to program
logic. Such changes require an examination of and
modification to test cases, their scripts, and test data. Just as
those changes take time to ripple through the first four
stages. They take similar time to reflect in test cases.

In point of fact the previous does not occur in practice. The
previous outlines a complete, deliberate, detailed testing
process with no randomness. If that occurred, then beta
testing and the need for beta testers would not. Beta testing
only occurs because complete testing as outlined cannot due
to either cost or time considerations.

In almost every instance of enterprise-developed software
the enterprise releases a "production" version, knowing full
well that errors exist. Thus they employ their users as beta
testers. Experience indicates that vendor-developed software
employs their users in the same manner, following any formal
period of beta testing with a production version providing an
informal (and indefinite) period of further beta testing.

Now software based on logic programming and the use of a
two-stage proof engine, a completeness proof and an
exhaustive true/false proof offers a means of automatic
testing complete in every sense in terms of test cases, test
scripts, and test data with minimal manual writing involved.
This occurs because logic programming offers two basic forms
of logic, clausal and predicate. They differ in that the clausal
logic form, e.g. SQL and Prolog, require external creation of
data while the predicate logic form, e.g. Trilogy, will create,
i.e. enumerate, all possible sets of test data based upon the
rules given for that data, i.e. the range of input values.

This doesn't change the fact that verification must still occur
manually. We do not violate any proof that software cannot
prove its own correctness. We do, however, have a means of
generating test data dynamically that completely tests the
logic of any program regardless of any change to that logic
over the course of the software's life cycle.

This results in logic programming not only automating the
stages of analysis, design, and construction, leaving only
specification as a manual writing function, but also extending
this automation to software testing as well.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 20 | April | 2004 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.