LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous (more recent) messageNext (less recent) messagePrevious (more recent) in topicNext (less recent) in topicPrevious (more recent) by same authorNext (less recent) by same authorPrevious page (March 1998, week 5)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Tue, 31 Mar 1998 10:43:53 -0600
Reply-To:     Jack Hamilton <jack_hamilton@HCCOMPARE.COM>
Sender:       "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From:         Jack Hamilton <jack_hamilton@HCCOMPARE.COM>
Subject:      Re: Quality Assessment
Comments: To: msd@INEL.GOV
Content-Type: text/plain; charset=US-ASCII

Mark DeHaan <msd@INEL.GOV> wrote:

>I had an interesting question posed to me today and wanted to get your input: > >How does one verify the accuracy of a software PACKAGE? How would one verify >that the PACKAGE is accurately doing what it is designed to do?

Yes, it is an interesting question, and there's no easy answer. A few possibilities:

- If there's another package that's supposed to accomplish the same function, run your numbers through both and compare the results.

- Double-code, and compare results. For example, if you are performing a bunch of calculations with data steps and procedures, try coding the problem in SQL instead (or vice-versa). You might also discover aspects of the problem that were hidden by your original method.

- Have code inspections, so that a different set of eyes and brains can check what you did.

- Create a test input dataset that contains lots of boundary conditions and pathological cases. Does your program produce the right results?

- If possible, create a visual representation of the answers. A graph will sometimes show problems that wouldn't be noticed in the sea of numbers produced by a tabular report.


Back to: Top of message | Previous page | Main SAS-L page