Software Testing (a (1D Kerry Zhu Zhu.kerry@gmaIl.com
Software Testing & QA (II) Zhu.Kerry@gmail.com Kerry Zhu
Testing Phases in SDlC System Other Customer o Unit Desig Functional software requirements User Specification requirements requirements specification Environment 3 Test 3 Unit Test oo3 Integration Function System Acceptance Installation Test Test Test Test Test 9=90 Integrated Functioning Verified, Accepted modules system validated test software System Unit use est
2 Testing Phases in SDLC Unit Test Integration Test Function Test Acceptance Test Installation Test System Test Unit Test Unit Test Components Design Specification System Functional requirements Other software requirements Customer requirements Specification User Environment Integrated modules Functioning system Verified, validated software Accepted test System in use Zhu.Kerry@gmail.com
Software Testing: Taxonomy yy purposes By life cycle phase By scope Correctness testing Requirements phase 3 Black-box testing Unit testing White-box Design phase testing -Component testing 3 Performance testing Program phase testing Integration testing Reliability testing Evaluating test results -System testing Robustness/strong Installation phase or In testing testing Unit testin Exception handling Acceptance testing -String testing testing Testing changes System testing a test Stress/load testing maintenance Acceptance testing(b Security testing test)
3 Software Testing: Taxonomy By purposes • Correctness testing – Black-box – White-box • Performance testing • Reliability testing - Robustness/strong testing - Exception handling testing - Stress/load testing • Security testing By life cycle phase • Requirements phase testing • Design phase testing • Program phase testing • Evaluating test results • Installation phase testing • Acceptance testing • Testing changes: maintenance By scope • implied in – Unit testing – Component testing – Integration testing – System testing • or in – Unit testing – String testing – System testing (a test) – Acceptance testing (b test) Zhu.Kerry@gmail.com
Part II: Testing Fundamentals N5天033983 4. EXamining the Specification 5. Testing the software with blinders on 6. EXamining the Code 7. Testing the Software with X-Ray Glasses Static Dynamic Data testing Black Box Examine MRD/PRD and specs State testing White Box Formal reviews Debug unit test
4 Part II: Testing Fundamentals ◼ 4. Examining the Specification. ◼ 5. Testing the Software with Blinders On. ◼ 6. Examining the Code. ◼ 7. Testing the Software with X-Ray Glasses. Black Box White Box Static Dynamic Examine MRD/PRD and specs Data testing State testing Formal reviews Debug, unit test Zhu.Kerry@gmail.com
Chapter 4 TESTING FUNDAMENTALS Examining the Specification
5 Chapter 4 TESTING FUNDAMENTALS Examining the Specification Zhu.Kerry@gmail.com
Software Development Life cycle N5天033983 MRD Review Fns Reviev QA Test Planning KP Test Resource Planning Test Strategy QR Functional MRD Engg Plan Test Plan SDLC PRODUCT REQUIREMENT PRODUCT DESIGN
6 Software Development Life Cycle QA KP PRODUCT REQUIREMENT QR MRD SDLC Functional Spec PRODUCT DESIGN - MRD Review - Test Resource Planning - FnS Review - Test Planning - Test Strategy Engg Plan Test Plan Zhu.Kerry@gmail.com
SPECIFICATION DOCUMENT 3.As we have seen, specifications are not easy to write o They are meticulously detailed(and often ponderous in g their wording Given even a simple program, rarely would two people program it the same way. We need to know what the user really wants One use for the specification document is that testers can find bugs even before a line of code is written
7 SPECIFICATION DOCUMENT • As we have seen, specifications are not easy to write. • They are meticulously detailed (and often ponderous in their wording) • Given even a simple program, rarely would two people program it the same way. We need to know what the user really wants. • One use for the specification document is that testers can find bugs even before a line of code is written. Zhu.Kerry@gmail.com
spec example 3 Let's see a example 3
8 Spec Example Let’s see a example Zhu.Kerry@gmail.com
What Happens If No spec 当· First, try to avoid such projects! 3 If you are stuck, you need to wait until you have the o software 3 Treat the software as the specification and explore it feature by feature Of course, you cannot tell if a feature is missing Start educating your company about the need to find bugs early in the development process
9 What Happens If No Spec • First, try to avoid such projects! • If you are stuck, you need to wait until you have the software. • Treat the software as the specification and explore it feature by feature. • Of course, you cannot tell if a feature is missing. • Start educating your company about the need to find bugs early in the development process! Zhu.Kerry@gmail.com
Why examining the spec N5天033983 In the past, most Software organizations are faced with a compelling need to Reduce cycle time Improve quality ° Reduce costs Improve productivity By Examining The Specification, we can We can find many bugs that we can't find through testing especially the logic design problems Find defects BEFORE production began ° Reduction of cost Shortening the software development life cycle
10 Why Examining the Spec ? ◼ In the past, most Software organizations are faced with a compelling need to: • Reduce cycle time • Improve quality • Reduce costs • Improve productivity ◼ By Examining The Specification, we can: • We can find many bugs that we can’t find through testing, especially the logic design problems. • Find defects BEFORE production began. • Reduction of cost. • Shortening the software development life cycle. Zhu.Kerry@gmail.com