Software Testing for Developer Introduction. Duvan Luong, Ph.D. Operational Excellence Networks

Size: px

Start display at page:

Download "Software Testing for Developer Introduction. Duvan Luong, Ph.D. Operational Excellence Networks"

Alannah Holt
5 years ago
Views:

1 Software for Developer Introduction Duvan Luong, Ph.D. Operational Excellence Networks

2 Contents Expectations for the class The software development model The reality of software defects The purpose of testing 4/2/2012 2

3 Expectations What do you expect to learn at the end of today training? This is the instructor! 4/2/2012 3

4 Software Development Model Validating Customers' Wants, Needs & Expectations Requirements Gathering Product Requirements Architecting CODE Design Product Architecture a Coding b1 b b2 c c1 c2 c3 d1 d d2 Designing 4/2/2012 4

5 Product Deliverables Structure MRD (Market Requirements Document) RRD (Release Requirements Document) Release V&V Plan Product Architecture PRS (Product Requirements Specifications) Test Plan Module Design Module Design Module Design FSpecs (Functional Specification) Test Case (Functional Specification) Code 4/2/2012 5

6 The Reality of Software Defects We all make mistakes Defects should be expected and planned for No such thing as defect free code 4/2/2012 6

7 Industry Statistics for Defect Introduction Design 45 % 20 % Requirements 35 % % of defect introduced by activity Code & Bad Fixes Reference: Caper Jones, "Applied Software Measurements", McGraw Hill, 1991 Reference: "CASE Make Strides toward Automated Software Development", Computer Design, January /2/2012 7

8 The High Cost of Defects 100 Relative Cost to Repair Specif. /Req. Design Coding Unit Test 20 Acceptance Test 50 Maintenance Phase in which Defect is Discovered/Repaired 4/2/2012 8

9 Defects Introduced by Life Cycle Phase Life Cycle Phase (Where Defects introduced) Requirements Gathering Architecting Designing Implementing/ Coding / Bug Fixing Product Supporting Requirements/ Specifications Functionality HW Interfaces SW Interfaces User Interfaces Functional Description Defect Type Process (Inter-process) Communication Data Definition Module Design Design Logic Description Error Checking Design Standards Code Logic Computation Data Handling Module Interface Implementation Code Standards Test HW Test SW Development Tools, Integration SW 4/2/2012 9

10 Defect Discovery Practice by Life Cycle Activities Life Cycle Activity Requirement Development Architecting Designing Implementing/ Coding Product Support Defect Discovery Practice Review Inspection Static Analysis Dynamic Analysis Unit Test Integration System Performance Stress Alpha Beta 4/2/

11 Defects Discovery by Quality Activities Quality Activity Review Inspection Unit Test Integration System Performance Stress Alpha Beta Requirements/ Specifications M M H H H M H Functionality M M H H H H H HW Interfaces M M H M SW Interfaces M M H H M User Interfaces M M H H H Functional Description H H M M M Defect Type Process (Interprocess) Communication M M H Data Definition H H H M M Module Design H M H M Design Logic Description H H M Error Checking H H H M M Design Standards H H H M Code Logic H H H Computation M M H Data Handling M M H M M M Module Interface Implementation M M M Code Standards H H M H Test HW M M M M M M Test SW M M M M M M Development Tools, Integration SW M M 4/2/

12 The Purpose of To find all the possible bugs debugging! To demonstrate that the product works fulfilling commitments to customers! Or to do both! 4/2/

13 Values and Approach Fundamental Premises Quality is a business decision is ENGINEERING does not exist apart from development is a significant means of performing risk management at the development level The result of testing is information, not quality Software development is not a turn-key process "Organic" in nature Requires a "system thinking" approach 4/2/

14 Quality is a Business Decision should not be something left to "CHANCE" Requires context, insight, experience, and engineering judgment Quality just not conformance to requirements Where do the requirements come from? Are the requirements documented? Customers do not require "absolute" quality; but they require "good enough" 4/2/

15 The Result of is Information, Not Quality Tests are an evaluation tool Tests do not fix anything by themselves Tests simply provide insight into a state What comes out of tests is information What is done with that information affects quality If test information is addressed, it will help optimize quality If test information is unknown or ignored, it may affect the quality 4/2/

Chapter 8: Verification & Validation

1 Chapter 8: Verification & Validation 2 Objectives To introduce software verification and validation and discuss the distinctions between them. V&V: Verification & Validation To describe the program inspection