1. Software Reviews & testing Software Reviews & testing An Overview

2. Objective To provide an overview of procedures for software reviews & testing activities To provide an overview of procedures for software reviews & testing activities

3. NOV-26-2003 AG/MKT/Overview 3 Intended audience Project team who are involved in software development, reviews & testing

4. NOV-26-2003 AG/MKT/Overview 4SDLC

5. NOV-26-2003 AG/MKT/Overview 5 UR Phase A preliminary phase to the software development life cycle called the ‘User Requirements Definition Phase' (UR phase). The UR phase is the ‘problem definition phase’ of a software project. The review of the URD is done by the users. The approved URD is the input to the SR phase.

6. NOV-26-2003 AG/MKT/Overview 6 SR Phase The SR phase is the ‘analysis’ phase of a software project. A vital part of the analysis activity is the construction of a ‘model’ describing ‘what’ the software has to do, and not ‘how’ to do it.

7. NOV-26-2003 AG/MKT/Overview 7 SR Phase The SRD must be reviewed formally by the users, by the computer hardware and software engineers, and by the managers concerned, during the Software Requirements Review (SR/R). The approved SRD is the input to the AD phase.

8. NOV-26-2003 AG/MKT/Overview 8 AD Phase The purpose of the AD phase is to define the “structure of the software”. This model is transformed into the architectural design by allocating functions to software components and defining the control and data flow between them.

9. NOV-26-2003 AG/MKT/Overview 9 DD Phase The purpose of the DD phase is to detail the design of the software, and to code, document and test it. During this phase, unit, integration and system testing activities are performed according to verification plans established in the SR and AD Phases. As well as these tests, there should be checks on software quality.

10. NOV-26-2003 AG/MKT/Overview 10 UR Reviews User requirements which are rejected in the review process do not have to be removed from the URD, especially if it is anticipated that resources may be available at some later date to implement them. Nonapplicable user requirements shall be clearly flagged in the URD.

11. NOV-26-2003 AG/MKT/Overview 11 SR Reviews The outputs of the SR phase shall be formally reviewed during the Software Requirements Review (SR/R). This should be a technical review Participants should include the users, the operations personnel, the developers and the managers concerned

12. NOV-26-2003 AG/MKT/Overview 12 ADD Reviews The architectural design should be reviewed and agreed layer by layer as it is developed during the AD phase. Walkthroughs should be used to ensure that the architectural design is understood by all those concerned. Inspections of the design, by qualified software engineers, may be used to eliminate design defects.

13. NOV-26-2003 AG/MKT/Overview 13 DDD Reviews The project leader should participate in these reviews, together with the team leader and team members concerned. After modules have been coded and successfully compiled, walkthroughs or inspections should be held to verify that the implementation conforms to the design..

14. NOV-26-2003 AG/MKT/Overview 14 End of Reviews By the end of the UR review, the SR phase section of the SPMP shall be produced (SPMP/SR). SCMP shall be produced (SCMP/SR). SVVP shall be produced (SVVP/SR). SQAP shall be produced (SQAP/SR) Acceptance Test Plan. During the SR phase, the AD phase section of the SPMP shall be produced (SPMP/AD). SCMP shall be produced (SCMP/AD). SVVP shall be produced (SVVP/AD). SQAP shall be produced (SQAP/AD). System Test Plan.

15. NOV-26-2003 AG/MKT/Overview 15 End of Reviews During the AD phase, DD phase section of the SPMP shall be produced (SPMP/DD). SCMP shall be produced (SCMP/DD). SVVP shall be produced (SVVP/DD). SQAP shall be produced (SQAP/DD). Integration Test Plan. During the DD phase, the TR phase section of the SPMP shall be produced (SPMP/TR). SCMP shall be produced (SCMP/TD). SVVP shall be produced (SVVP/TD). SQAP shall be produced (SQAP/TD). Unit Test Plan.

16. NOV-26-2003 AG/MKT/Overview 16 Reviews improve schedule performance Reviews reduce rework. Rework accounts for 44% of development. Cost! Requirements (1%) Design (12%) Coding (12%) Testing (19%) Reviews are pro-active tests. - Find errors not possible through testing. Reviews are training. - Domain, corporate standards, group.

17. Testing activities 1.Unit Testing 2.Module/ Integration Testing 3.System Testing 4.Acceptance Testing 5.User Documentation Review

18. Unit Testing This is the testing performed on the most basic item of the software product i.e. the individual source code component to uncover the errors and to ensure that this is meeting all the specifications as described in SDD. Testing activities

19. Module/Integration Testing This is the testing performed at sub-system level to uncover errors related to interfacing. Testing activities

20. System Testing System testing is a validation activity used to demonstrate that the entire software product is conforming to the user requirement expressed and agreed upon earlier. This test is carried out after integrating all the components of the product in a common environment. Testing activities

21. Acceptance Testing Acceptance testing is a validation activity before the system is accepted by the user for operational use. Testing activities

22. User Documentation Review This is to verify that the user documentation has explained all the features of the software delivered correctly and clearly along with the operational procedure. Testing activities

23. Testing: A process of executing a program with the intent of finding an error A good test has a high probability of finding an undiscovered error A successful test uncovers an undiscovered error Testing Objectives

24. Testing strategy is a road map describing –Steps to be conducted as part of testing –When these steps should be planned and undertaken –How much effort, time, and resources will be required. Testing strategy

25. Testing strategy must incorporate –Test planning –Test case design –Test execution –Data collection and evaluation Testing strategy

26. NOV-26-2003 AG/MKT/Overview 26 Test known internal workings to assure that internal operation performs according to specs. Tests logical paths and procedural detail Test known internal workings to assure that internal operation performs according to specs. Tests logical paths and procedural detail Using white box testing, the software engineer can derive test cases that Using white box testing, the software engineer can derive test cases that –Guarantee that all independent paths within a module have been exercised at least once –Exercise all logical decisions on the their true and false sides –Execute all loops at their boundaries and within their operational bounds –Exercise internal data structures to assure their validity White Box Testing

27. Focuses on functional requirements of software Focuses on functional requirements of software –Incorrect or missing functions –Interface errors –Error in data structure & external data base access –Performance errors –Initialization & termination errors Tends to be applied during later stages of testing Tends to be applied during later stages of testing Black Box Testing

28. Number of possible logical paths, even in small programs, can be extremely large Therefore exhaustive white box testing is impractical Often the best test strategy is to perform both white box and black box testing Test Case Design

29. Flow Graph Notation One or more non-branching PDL or source code statements Sequence If While Until Case

30. Flow Graph 1 2,3 10 11 6 78 9 4,5 Edg e Node Region R1R1 R4R4 R3R3 R2R2

31. Nodes, Edges, And Regions Each circle is a node and represents one or more procedural statements (a sequence of process boxes and decision diamonds can map into a single node; each node that contains a condition is called a predicate node Arrows are called edges and must terminate at a node Areas bounded by edges and nodes are called regions, including the area outside the graph

32. Cyclomatic Complexity Cyclomatic complexity provides a quantitative measure of the logical complexity of a program –It is the upper bound for the number of tests that must be conducted to assure that all statements have been executed at least once Cyclomatic complexity, V(G) is given by the graph V(G) = E - N + 2, where E is the number of flow graph edges and N is the number of flow graph nodes V(G) = P + 1, where P is the number of predicate nodes contained in the flow graph V(G) = number of regions

33. Unit Testing Interface Local data structure Boundary conditions Independent paths Error-handling paths

34. Boundary Testing Last and probably most important unit test step –Errors often occur when nth element of n- dimensional array is processed, when ith repetition of loop with i passes is invoked, when max or min allowable value is encountered –Exercise data structure, control flow, and data values just below, at, and just above maxima and minima

35. Integration Testing Construct program structure while testing to uncover errors associated with interfacing –Data can be lost across interface –One module can have an inadvertent adverse effect on another module –Subfunctions, when combined, may not provide the desired total function –Individually acceptable imprecision may be magnified to unacceptable levels

36. System Testing Recovery testing is a system test that forces software to fail in a variety of ways and verifies that recovery is performed Security testing attempts to verify that system protection systems work Stress testing executes a system in an abnormal manner - frequency of interrupts, input data rates, use of memory Performance testing - resource utilization, execution intervals

37. NOV-26-2003 AG/MKT/Overview 37 Process - Review & testing activities For detailed descriptions & tasks of review & testing activities, refer to process manual - Software Verification, Validation & Testing (SVVT) Manual

38. Thank You