Improvement Testing

Improvement Testing Improvement Testing Program Testing • Testing is expected to show that a program does what it is planned to do and to find program defects before it is put into use. • When you test software, you execute a program using fake data. • You check the results of the test for errors, inconsistencies, or information about the program's non-functional qualities. • Testing can uncover the presence of errors, NOT their absence. • Testing is part of a broader verification and validation process, which also includes static validation techniques. Program Testing Objectives • To show to the developer and the client that the software meets its requirements. o • For custom software, this means that there should be at least one test for each requirement in the requirements document. For generic software products, it means that there should be tests for all of the system features, in addition to combinations of these features, that will be included in the product release. To find circumstances where the behavior of the software is incorrect, poor, or doesn't conform to its specification. o Defect testing is concerned with uncovering poor system behavior, such as system crashes, unwanted interactions with other systems, incorrect calculations, and data corruption. Validation and Defect Testing • The primary objective leads to validation testing: o • You expect the system to perform correctly using a given set of experiments that reflect the system's normal use. The subsequent objective leads to defect testing: o The experiments are designed to uncover defects. The experiments in defect testing can be deliberately obscure and need not reflect how the system is typically used. 1 Testing Process Objectives • • Validation Testing o To demonstrate to the developer and the system user that the software meets its requirements. o A successful test shows that the system works as expected. Defect Testing o To find faults or defects in the software where its behavior is incorrect or not in conformance with its specification. o A successful test is one that causes the system to perform incorrectly, thus exposing a defect in the system. Check versus Validation • • Check: o "Are we building the product right?" o The product should conform to its specification. Validation: o "Are we building the right product?" o The product should meet the user's expectations. V and V Confidence • The point of V and V is to establish confidence that the system is 'fit for purpose.' • Relies upon the system's purpose, user expectations, and marketing environment: o Software Purpose:  o User Expectations:  o The level of confidence depends on how critical the software is to an organization. Users may have low expectations for certain types of software. Marketing Environment:  Getting a product to market early may be more important than finding defects in the program. 2 Examinations and Testing • • Software Examinations are concerned with the analysis of the static system representation to find issues (static verification). o May be supplemented by tool-based documentation and code analysis. o Discussed in Part 15. Software Testing is concerned with exercising and observing product behavior (dynamic validation). o The system is executed with test data, and its functional behavior is observed. Software Examinations • These involve people analyzing the source representation with the goal of finding anomalies and defects. • Reviews do not require the execution of a system, so they may be used before execution. • They may be applied to any representation of the system (requirements, design, configuration data, test data, etc.). • They have been shown to be an effective technique for finding program defects. Benefits of Reviews • During testing, errors can hide other errors. Since a review is a static process, you don't need to worry about interactions between errors. • Incomplete versions of a system can be reviewed without additional costs. If a program is incomplete, you can develop specific test suites to test the parts that are available. • In addition to searching for program defects, a review can also consider broader quality attributes of a program, such as compliance with standards, portability, and feasibility. 3 Reviews and Testing • Reviews and testing are complementary and not conflicting validation techniques. • Both should be used during the V and V process. • Reviews can check conformance with a specification but not conformance with the user's actual needs. • Reviews cannot check non-functional attributes like performance, usability, etc. 4