SUGI 28: Beyond Debugging: Program Validation

1 Paper 58- 28 beyond debugging : Program Validation Neil Howard, Ingenix, Basking Ridge, NJ Abstract "Act in haste and repent at leisure; code too soon, and debug forever." Raymond Kennington In their paper on debugging , Lora Delwiche and Susan Slaughter say that good debuggers make good programmers. Let's take that one step further to say that good analysts and problem-solvers make good programmers. Just because a SAS Program is free of errors, warnings, notes, and bugs does not guarantee that the Program is doing what it is supposed to do.

2 This tutorial addresses the process that follows debugging : Program Validation . It covers techniques for ensuring that the logic and intent of the Program is correct, that the requirements and design specifications are met, and that data errors are detected. It also discusses fundamental SAS Program design issues that give purpose and structure to your programming approach. This paper will address: the definitions of verification, Validation , testing, and debugging , as well as the structure of the Software Development Life Cycle (SDLC).

3 It will illustrate how the SAS system can be used to help satisfy the requirements of your SDLC and accomplish the tasks of verification and Validation . Since as much as 80% of a programmer s time is invested in testing and Validation , it s important to focus on tools that facilitate correction of syntax, data, and logic errors in SAS programs . The presentation focuses on wide variety of SAS features, tips, techniques, tricks, and system tools that can become part of your routine testing methodology.

4 Introduction [..Overheard at an interview for a SAS programming position: But you don t have to test SAS programs !!! ..] As the interviewers quickly escort the confused candidate out the door, they recall how often it is assumed that a fourth generation language does so much for you that you don t have to test the code. The SAS system is easy to use, and the learning curve to productivity is relatively short. But SAS is just as easy to ABUSE. Programmers and analysts must not lose sight of the indisputable facts: data is seldom clean, logic is too often faulty, and fingers walk clumsily over keyboards.

5 Condition codes are not an accurate indicator of successful programs . There are traditional methodologies for preventative pest control, but there is no PROC TEST-MY-CODE or PROC WHITE-OUT or PROC READ-MY-MIND. The SAS system offers many features for identifying syntax, logic, and data errors. The results will undoubtedly include reduced stress and bigger raises for SAS programmers, satisfied clients, accurate output, and quality programs that are reliable and maintainable. This supports the business need to deliver results to the FDA, minimize time to approval and time to market.

6 Definition of Terms The responsibility for ensuring Program quality remains with the programmer. Today's competitive environment demands that we discuss testing methods and useful SAS system tools that will help us meet the challenges of verification, Validation , testing, and debugging . The following definitions were provided by the Validation maven at Parke-Davis and serve as the benchmarks for this paper. VERIFICATION: Checking (often visual) of a result based on predetermined criteria, , check that a title is correct.

7 Validation : The process of providing documented evidence that a computerized system performs its functions as intended and will continue to do so in the future. TESTING: Expected results are predetermined, so actual results can be either accepted or rejected by one or more of the testing types: unit, integration, worst case, valid case, boundary value, alpha, beta, black box, white box, regression, functional, structural, performance, stability, etc. debugging : The process of finding and correcting the root cause of an unexpected result.

8 Terms are Relative The author conducted a brief informal survey: 1) within Parke-Davis, among the Clinical Reporting Systems management team, selected senior programmers and systems analysts, clinical team leaders, developers and biometricians, and 2) Beyond the company, within a selected network of colleagues in the SAS community. The intent of the survey was SUGI 28 Beginning Tutorialsto see how well our baseline definitions help up against greater scrutiny, perception and application. IEEE on Terms One survey respondent follows the Teri Stokes school of Validation , based on IEEE standards.

9 Std 1012-1986, "IEEE Standard for Software Verification and Validation Plans", states: VERIFICATION is "the process of determining whether or not the products of a given phase of the software development cycle fulfill the requirements established during the previous phase." Informally, making sure your Program is doing what you think it does. Validation is "the process of evaluating software at the end of the software development process to ensure compliance with software requirements." Informally, making sure the client is getting what they wanted.

10 TESTING is "the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs), and to evaluate the features of the software item." IEEE Standard , "IEEE Standard Glossary of Software Engineering Terminology, offers DEBUG: "To detect, locate, and correct faults in a computer Program . Techniques include use of breakpoints, desk checking, dumps, inspection, reversible execution, single-step operation, and traces." Survey Results For the most part, the survey respondents were consistent in their definitions, especially for Validation and debugging .