RE: Test data laziness :)

I wasn't suggesting that it was a GOOD idea, just possible. I would
agree with your suggestion of creating test cases, but volume testing is
a must as well. I'm sure we've all seen programs that run fine against
30 test cases, but run for 20 hours against 500,000 real data records.

-Walden

-----Original Message-----
From: Vanya Jovic [mailto:jovic@calcna.ab.ca]
Sent: Thursday, June 11, 1998 8:31 PM
To: MIDRANGE-L@midrange.com
Subject: RE: Test data laziness :)




        Walden,
Is it really good idea to abuse wholes in security of you own system? In
"super secured" machine scenario, DDM will usually trigger remote job
with
QUSER user-id, which again in "super secured" scenario usually has
*ALLOBJ
authority and that means that your limited ID doesn't protect you any
more
from damaging production data.

        Besides, whole idea of testing is not about prooving that your
program works, but rather that it doesn't work :))). In stead of
spending
7 days creating mass data (which is also important part of testing), I
would go with test cases, created to check if program satisfies all
design
requirements, and than with some "wired" cases to check program's
ability
to handle unusual and extreme situations. One carefully chosen record
(especially if you follow it with suorce debugger) can be better
solution
than 100000+ mass stream, which would only give you some numbers that
nobody understands. 

Take care
Vanya


On Wed, 10 Jun 1998, Walden Leverich wrote:

> 
> Take a look at DDM. You can create DDM files for each of the logicals
> that point at the real logicals on the production machine. Of course,
> this defeats the security of the production system (well it doesn't
> defeat it, you still can't do anything you're not authorized to, but
> you'd be surprised of the number of "super secured" machines I've
worked
> on that were not all that secure).
> 
> -Walden
> 
> -----Original Message-----
> From: Tim Truax [mailto:truax@usaor.net]
> Sent: Monday, June 08, 1998 10:46 PM
> To: MIDRANGE-L list
> Subject: Test data laziness :)
> 
> 
> Hello and Happy "belated" D-Day....lest we ever forget.
> ---------
> Here's my question, and feel free to call me a lazy b*st*rd....
> I am working on a LARGE program that produces a large critical report.
> Now this program uses about 30 files, 22 of which are logicals that
are
> built over various and sundry physical files.  6 of the files are
major
> join files that bring together the data of multiple physical files
> around the production system.  Now, I work on a developement machine
> (hardly any security) that is seperate from the production environment
> (super secured environment) (passthru is the way we can access the
> different systems) this developement machine has bits and pieces of
the
> actual types of data that reside on the production machine... but of
> course the data would have to be recreated on the developement machine
> for me to be able to test the program properly.  Is my only
alternative
> to just slug it out and collect all these physical file pieces and
parts
> and then SNDNETF them to the developement machine into my test library
> and then recreate the logicals that will connect the physical file
> pieces and parts as well as the join files?  Any other suggestions?
> I guess..... I should just sit down for a week and write a program
that
> will automatically produce any type of needed data samplings.... Is
this
> what you nice people are  gonna suggest?
> ----
> Tim & Dana Truax... and Caleb 4 years old.
> 
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---
> 

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---