1. 1 Software Testing and Quality Assurance Lecture 2 Software Verification & Validation

2. 2 Lecture Outline Static V &V techniques Walkthroughs. Technical Reviews. Software Inspections.

3. 3 Walkthroughs Usually done in a single meeting. Evaluate a software product to Find anomalies & improve the software product. Consider alternative implementations. Evaluate the conformance to standards and specification. Perform training of the project teams.

4. 4 Suitability for the intended use? Technical Reviews Software Product Review Report Action Item List Technically Qualified Team Evaluates Rework/Follow-up

5. 5 Software Inspection Formalized approach to document reviews. Intended explicitly for defect detection (not correction). Defects may be logical errors & anomalies in the code. For example, An un-initialized variable Non-compliance with standards.

6. 6 Software Inspection Remove errors as near source as possible; hence, reducing costs of rework. It’s success depends on The inspection process, Checks applied; The diligence of the inspectors.

7. 7 Inspection pre-conditions Precise specification must be available. Team members must be familiar with the organization standards. Inspections will increase costs early in the software process.

8. 8 Software Inspections Time No. of Employees Planning Requirements DesignCoding Testing Without Inspection With Inspection

9. 9 Inspection Process Planning Overview Individual Preparation Rework Follow-up Inspection Meeting

10. 10 Inspection Steps Reader paraphrases design, describing how it will be implemented. Questions raised during discourse, only pursued until error recognized. Error noted (but not solution) and classified by severity. Written report of inspection prepared. Important to inspect modified products. Re-inspection to avoid ‘bad fix’ problems.

11. 11 Software Inspection Overview Operation 1 I Rework Analysis Fix short term problems Error feedback Learning input for inspectors What error types to look for Better ways to find error types Feedback

12. 12 Feedback Inspection provide detailed real-time feedback to developers Process control using inspection Identification of error prone modules; and Distribution of error types Inspections should lead to Process Improvement

13. 13 Feedback Inspection success depends on Management attitude Conduct of trained moderator Inspections should not be used for performance appraisals

14. 14 Software Inspection Overview Operation 1Operation 2 I Rework Analysis Fix short term problems Error feedback Learning input for inspectors What error types to look for Better ways to find error types Error prone modules ranked. Error types distributions ranked For Special Attentions Feedback Feed forward

15. 15 Rate of Progress Rate of progress (man/hours) Process OperationsDesignCodeobjectives Overview500-communication preparation100125education inspection130150Find errors Rework2016Remove errors Follow-up--Ensure resolutions of errors

16. 16 Error Analysis Finding errors is difficult Condition people to seek high occurrence, high cost error types. Take representative sample of code; Analyze errors Type and origin of error; cause and salient indicative feature

17. 17 Stages of Static Analysis

18. 18 Control Flow Analysis Condition statements; Is the condition correct? Loop statements; Is each loop certain to terminate? Case statements; Are all possible cases accounted for?

19. 19 Data Check Are all program variables initialized before their values are used? Have all constants be used? Is there any possibility of buffer overflow?

20. 20 Interface Analysis Do all function and method calls have the correct number of parameters? Are the parameters in the right order?

21. 21 London Ambulance Service Case Study Computer Aided Dispatch Server Automatic Vehicle Location System Radio Communication Infrastructure Ambulance PRINCE Development Methodology was selected for the development

22. 22 London Ambulance Service Case Study Throughout the project there are references to only functional testing No static V & V process. The draft project plan as provided by the supplier left no time for review and revision. As a result, …….. For example, Lack of formal clarification how the PRINCE methodology was to be applied.

23. 23 Key Points Focus objectives of static V &V techniques such as software inspection. Identify error types to get maximum benefits out of static V & V techniques. Analyze inspection results and use it for process improvement.