WHY TEST SOFTWARE?...

Similar documents
Testing. ECE/CS 5780/6780: Embedded System Design. Why is testing so hard? Why do testing?

Software Testing. An Overview

1 Visible deviation from the specification or expected behavior for end-user is called: a) an error b) a fault c) a failure d) a defect e) a mistake

Testing Objectives. Successful testing: discovers previously unknown errors

Types of Software Testing: Different Testing Types with Details

Sample Exam Syllabus

MONIKA HEINER.

Cursul Aprilie

CSE 403: Software Engineering, Fall courses.cs.washington.edu/courses/cse403/16au/ Unit Testing. Emina Torlak

Quote by Bruce Sterling, from: A Software Testing Primer, Nick Jenkins

Write perfect C code to solve the three problems below.

Part I: Preliminaries 24

QUIZ #5 - Solutions (5pts each)

Higher-order Testing. Stuart Anderson. Stuart Anderson Higher-order Testing c 2011

Examination Questions Time allowed: 1 hour 15 minutes

Quality Assurance: Test Development & Execution. Ian S. King Test Development Lead Windows CE Base OS Team Microsoft Corporation

Lecture 15 Software Testing

Manuel Oriol, CHCRC-C, Software Testing ABB

Bridge Course On Software Testing

Software Testing 2. OOD and Testability. White box vs Black box Testing. Software Testing 2 Semester 1, 2006

Testing. Prof. Clarkson Fall Today s music: Wrecking Ball by Miley Cyrus

Software Quality Assurance. David Janzen

CYSE 411/AIT 681 Secure Software Engineering. Topic #6. Seven Software Security Touchpoints (III) Instructor: Dr. Kun Sun

Topic: Software Verification, Validation and Testing Software Engineering. Faculty of Computing Universiti Teknologi Malaysia

4. Risk-Based Security Testing. Reading. CYSE 411/AIT 681 Secure Software Engineering. Seven Touchpoints. Application of Touchpoints

Chapter 10. Testing and Quality Assurance

Basic Training in Software Testing (2 Days)

CAPABILITY. Managed testing services. Strong test managers experienced in working with business and technology stakeholders

Department of Electrical & Computer Engineering, University of Calgary. B.H. Far

Certified Tester Foundation Level(CTFL)

Certified Software Quality Engineer Preparation On Demand, Web-Based Course Offered by The Westfall Team

Software Testing MANUAL TESTING. Introduction to Testing. Software Quality Software Testing Definition. Different Life Cycle Models Waterfall Model

INTRODUCTION TO SOFTWARE ENGINEERING

Part 5. Verification and Validation

Software Testing. Testing: Our Experiences

Software Testing Techniques

Ontology Summit 2013: Ontology Evaluation Across the Ontology Lifecyle Track B: Extrinsic Aspects of Ontology Evaluation

Software Development. Software Testing: Verification and Validation. Verification and Validation (V&V) Verification. Validation

Testing Mission Critical Applications MCP UNITE 2012

Manual Testing. Software Development Life Cycle. Verification. Mobile Testing

Security Engineering for Software

Sample Exam. Certified Tester Foundation Level

Chapter 8 Software Testing. Chapter 8 Software testing

Software Testing. Software Testing. in the textbook. Chapter 8. Verification and Validation. Verification Techniques

No Source Code. EEC 521: Software Engineering. Specification-Based Testing. Advantages

Three General Principles of QA. COMP 4004 Fall Notes Adapted from Dr. A. Williams

113 BSIMM Activities at a Glance

Chapter 9. Software Testing

Black Box Testing. EEC 521: Software Engineering. Specification-Based Testing. No Source Code. Software Testing

Software Testing. Software Testing. in the textbook. Chapter 8. Verification and Validation. Verification and Validation: Goals

18-642: Testing Overview

Verification, Testing, and Bugs

Learning outcomes. Systems Engineering. Debugging Process. Debugging Process. Review

Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement

Govt. of Karnataka, Department of Technical Education Diploma in Information Science & Engineering. Sixth Semester

Software Quality. Richard Harris

Diploma in Software Testing (DST)

It is primarily checking of the code and/or manually reviewing the code or document to find errors This type of testing can be used by the developer

Test Oracles and Mutation Testing. CSCE Lecture 23-11/18/2015

csc444h:& so(ware&engineering&i&

Software Testing. Hans-Petter Halvorsen, M.Sc.

Taking White Hats to the Laundry: How to Strengthen Testing in Common Criteria

How to Harvest Reusable Components in Existing Software. Nikolai Mansurov Chief Scientist & Architect

ViGo Architecture and Principles. Mobile Voice Biometrics as-a-service

Comparison Study of Software Testing Methods and Levels- A Review

Dataworks Development, Inc. P.O. Box 174 Mountlake Terrace, WA (425) fax (425)

Computer Science and Software Engineering University of Wisconsin - Platteville 9-Software Testing, Verification and Validation

FPGA Verification How to improve verification without throwing everything away

Testing! Prof. Leon Osterweil! CS 520/620! Spring 2013!

a. The following method would allow an object of the static type List<String> to be passed to it as an argument.

Verification & Validation of Open Source

Testing. Topics. Types of Testing. Types of Testing

Development. Architecture QA. Operations

Darshan Institute of Engineering & Technology for Diploma Studies

Objectives. Chapter 19. Verification vs. validation. Topics covered. Static and dynamic verification. The V&V process

Chapter 11, Testing. Using UML, Patterns, and Java. Object-Oriented Software Engineering

Sample Exam. Advanced Test Automation Engineer

Diploma in Software Testing 2.0 (HP)

Sample Question Paper. Software Testing (ETIT 414)

10. Software Testing Fundamental Concepts

Verification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1

Testing is the process of evaluating a system or its component(s) with the intent to find whether it satisfies the specified requirements or not.

lecture'7:' quality'assurance'

Software Testing CS 408

Simple Overflow. #include <stdio.h> int main(void){ unsigned int num = 0xffffffff;

Sample Exam ISTQB Advanced Test Analyst Answer Rationale. Prepared By

PASS4TEST. IT Certification Guaranteed, The Easy Way! We offer free update service for one year

Automatically Finding Patches Using Genetic Programming. Westley Weimer, Claire Le Goues, ThanVu Nguyen, Stephanie Forrest

Preview from Notesale.co.uk Page 4 of 186

Oracle Developer Studio Code Analyzer

Module 1 : Fundamentals of Testing. Section 1: Manual Testing

Basics of Software Testing-I UNIT I Software Testing. Software is used in many applications of the real world. Some of the examples are

The testing process. Component testing. System testing

Ready to Automate? Ready to Automate?

Administrivia. ECE/CS 5780/6780: Embedded System Design. Acknowledgements. What is verification?

Software Design Models, Tools & Processes. Lecture 6: Transition Phase Cecilia Mascolo

Shift Left and Friends And What They Mean for Testers

WHITE PAPER. 10 Reasons to Use Static Analysis for Embedded Software Development

Budapest, October 2016 FUZZ TESTING ITS. Presented by Jürgen Großmann and Dorian Knoblauch. All rights reserved

VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

Transcription:

2 At a glance 1 PREFACE... 3 2 AT A GLANCE... 5 3 TABLE OF CONTENTS... 9 4 INTRODUCTION... 17 5 WHY TEST SOFTWARE?... 19 5.1 WHY TEST SOFTWARE?... 19 5.2 LIMITATIONS OF TESTING... 20 5.3 ALTERNATIVE TO TESTING PROVING... 38 5.4 THREE OBJECTIVES OF TESTING SOFTWARE... 39 6 WHAT S SOFTWARE TESTING ABOUT?... 43 6.1 THE DIFFERENCE BETWEEN A TESTER AND A DEVELOPER... 43 6.2 THE THREE-HEADED DRAGON OF SOFTWARE DEVELOPMENT... 46 6.3 THE LANGUAGE OF SOFTWARE TESTING... 48 6.4 A BUG S LIFE... 54 6.5 SEVERITY OF BUGS... 56 6.6 THE KINDS OF BUGS... 59 7 STAGES OF SOFTWARE DEVELOPMENT FOR A TESTER... 72 5

6 7.1 CHALLENGING REQUIREMENTS... 72 7.2 CHALLENGING SPECIFICATIONS... 73 7.3 CHALLENGING ARCHITECTURE AND TECHNICAL DESIGN 79 7.4 TESTING CODE... 81 7.5 CHALLENGING DOCUMENTATION... 81 7.6 RELEASE... 83 8 DIMENSIONS OF SOFTWARE TESTING... 85 8.1 WHY DIMENSIONS?... 85 8.2 BY OBJECT... 86 8.3 BY SOURCE CODE VISIBILITY... 86 8.4 BY LEVEL... 88 8.5 BY PLACE... 93 8.6 BY PURPOSE... 95 8.7 BY ATTACK SURFACE... 116 8.8 BY FAULT TYPE... 123 9 QUALITY OF TESTING... 131 9.1 HUH?... 131 9.2 CODE COVERAGE... 131 9.3 SOFTWARE METRICS... 132 9.4 TEST PLAN REVIEW... 133 9.5 SEEDING BUGS AND CODE MUTATION... 134 9.6 TESTABILITY... 134 9.7 BETA RELEASE/BETA TESTING... 136 10 POST-RELEASE FUN... 138 10.1 DEPLOYMENT TESTING... 139 10.2 COMPATIBILITY TESTING... 139 10.3 SYSTEM TESTING... 139 10.4 STAGING AND PRODUCTION ENVIRONMENT... 140 11 TESTING SOFTWARE IN A GLOBAL TEAM... 141 11.1 TECHNICALLY SPEAKING... 141 11.2 HUMAN-ORIENTED... 142 12 SURVIVING AS A TESTER... 145 12.1 FUZZY VALUE IN THE SOFTWARE DEVELOPMENT.. 145

12.2 COST/VALUE BALANCE... 146 12.3 RELIGIONS AND CONFESSIONS... 147 12.4 IEEE ROLE... 151 12.5 OFFICE POLITICS... 151 12.6 OUTSOURCING AND JOB SECURITY... 154 12.7 SEGREGATION... 157 12.8 FUTURE OF THE TRADE... 158 13 APPENDIX A. TEST CASE... 168 14 APPENDIX B. BIBLIOGRAPHY... 170 14.1 STANDARDS AND CLASSICS... 170 14.2 EXTREME TESTING & RELATED... 171 14.3 OTHER... 172 15 ENDNOTES... 174 7

3 Table of Contents 1 PREFACE 3 2 AT A GLANCE 5 3 TABLE OF CONTENTS 9 4 INTRODUCTION 17 5 WHY TEST SOFTWARE? 19 5.1 WHY TEST SOFTWARE? 19 5.2 LIMITATIONS OF TESTING 20 5.2.1 The First Law of Software Programming 20 5.2.2 Nothing is ever perfect 21 5.2.2.1 Requirements 22 5.2.2.2 Design 23 5.2.2.2.1 Requirements context, missed or ignored requirements 24 5.2.2.2.2 Overusing formal verification tools without proper qualification 27 5.2.2.2.3 Late design changes and code fixes 29 5.2.2.3 Code 29 5.2.2.4 Platform 30 5.2.2.5 Tests 30 5.2.2.6 Users 31 5.2.2.6.1 Monkey 32 9

10 5.2.2.6.2 Farmer 33 5.2.2.6.3 Hacker 34 5.2.2.7 The Product Team 34 5.2.3 Richness of possibilities 34 5.2.3.1 Code paths, state transitions 35 5.2.3.2 Inputs (including input editing and timing) 36 5.2.3.3 Data in the environment 37 5.2.3.4 In essence you cannot try everything 38 5.3 ALTERNATIVE TO TESTING PROVING 38 5.4 THREE OBJECTIVES OF TESTING SOFTWARE 39 5.4.1 So, why? 39 5.4.2 Objective #1: Quality Bar 39 5.4.3 Objective #2: Acceptance 41 5.4.4 Objective #3: Baseline 41 6 WHAT S SOFTWARE TESTING ABOUT? 43 6.1 THE DIFFERENCE BETWEEN A TESTER AND A DEVELOPER 43 6.1.1 A Castle 43 6.1.2 Debugging is not testing 44 6.1.2.1 Goals 44 6.1.2.2 Actor 45 6.1.2.3 Tools 45 6.1.2.4 Results 45 6.1.3 Super-pessimism Testing that the glass is half empty 45 6.2 THE THREE-HEADED DRAGON OF SOFTWARE DEVELOPMENT 46 6.2.1 Software developer 46 6.2.2 Software architect, analyst, project manager 47 6.2.3 Software tester 48 6.3 THE LANGUAGE OF SOFTWARE TESTING 48 6.3.1 The bug: what is it? 48 6.3.2 Test case 49 6.3.3 Test plan 50 6.3.4 Bug tracking 50 6.3.5 Version control 51 6.3.6 Test automation 53 6.4 A BUG S LIFE 54

6.4.1 Bug opened 54 6.4.2 Bug approved 55 6.4.3 Bug fixed 55 6.4.4 Bug verified and closed 56 6.5 SEVERITY OF BUGS 56 6.5.1 Know Thine User! 57 6.6 THE KINDS OF BUGS 59 6.6.1 Code defect 59 6.6.2 Crash 60 6.6.3 A special kind: Regression 61 6.6.4 Security 61 6.6.5 Performance-related 62 6.6.5.1 Throughput (performance) 62 6.6.5.2 Stress 63 6.6.5.3 Volume 64 6.6.5.4 Scalability 64 6.6.5.5 Resources consumption (leaks) 65 6.6.6 Usability 67 6.6.7 Documentation 69 6.6.8 Test issue 70 6.6.8.1 Bugs in tests and frameworks 70 6.6.8.2 Mixing up a bug and a feature 70 7 STAGES OF SOFTWARE DEVELOPMENT FOR A TESTER 72 7.1 CHALLENGING REQUIREMENTS 72 7.2 CHALLENGING SPECIFICATIONS 73 7.2.1 Challenging assumptions 74 7.2.2 Challenging completeness 75 7.2.3 Challenging behavior 77 7.2.4 Challenging usability 78 7.2.5 Challenging testability 78 7.2.6 That s not the end 79 7.3 CHALLENGING ARCHITECTURE AND TECHNICAL DESIGN 79 7.4 TESTING CODE 81 7.5 CHALLENGING DOCUMENTATION 81 7.6 RELEASE 83 8 DIMENSIONS OF SOFTWARE TESTING 85 11

12 8.1 WHY DIMENSIONS? 85 8.2 BY OBJECT 86 8.2.1 Positive testing capabilities 86 8.2.2 Negative testing environment 86 8.3 BY SOURCE CODE VISIBILITY 86 8.3.1 Black ( opaque ) box testing 86 8.3.2 White (glass, clear) box testing 87 8.3.3 Gray ( Translucent ) box testing 88 8.4 BY LEVEL 88 8.4.1 Unit testing 88 8.4.2 Component testing 89 8.4.3 Integration testing 90 8.4.4 System testing 91 8.4.4.1 Scenario-based 92 8.4.4.2 Free-form 92 8.5 BY PLACE 93 8.5.1 Product Team Testing (vendor) 93 8.5.2 Customer (user) Side Testing 93 8.5.3 Third Party Testing (certification) 94 8.6 BY PURPOSE 95 8.6.1 Functional testing 95 8.6.2 Regression testing 96 8.6.3 Performance related testing 97 8.6.3.1 Performance (throughput) testing 97 8.6.3.2 Volume (size) testing 97 8.6.3.3 Load (stress) testing 98 8.6.3.4 Scalability testing 98 8.6.3.5 Resource consumption (including leaks) testing 98 8.6.3.6 Sizing guidance 99 8.6.4 Conformance testing 99 8.6.4.1 Standards 100 8.6.4.2 Legislation 100 8.6.4.3 Coding policy testing 100 8.6.5 Security testing 100 8.6.5.1 Functional security testing 100 8.6.5.2 Security model and STRIDE 101 8.6.5.3 Security penetration testing 103 8.6.6 Globalization testing 103

8.6.6.1 Encoding 103 8.6.6.2 Watch your language 104 8.6.6.3 Formats 106 8.6.6.4 More calendar fun 106 8.6.6.5 Units 107 8.6.6.6 Strings 108 8.6.6.7 Length of text 108 8.6.6.8 Making of an error message 109 8.6.6.9 That s not all 110 8.6.7 Localization testing 110 8.6.7.1 Cultural differences 111 8.6.8 Platform and dependencies testing 112 8.6.9 Pseudo-testing 114 8.6.9.1 Usability 114 8.6.9.2 Reliability 115 8.6.9.3 Robustness 115 8.7 BY ATTACK SURFACE 116 8.7.1 What is an attack surface 116 8.7.2 Input 117 8.7.2.1 Input GUI 117 8.7.2.2 Input API 118 8.7.2.3 Input Files and DB content 119 8.7.3 Environment 119 8.7.3.1 Environment Resources (storage, memory, etc.) 119 8.7.3.2 Environment Access rights 120 8.7.3.3 Environment Network 120 8.7.3.4 Environment Files and folders 120 8.7.3.5 Environment Media 121 8.7.3.6 Environment Output devices 121 8.7.3.7 Environment Platform 122 8.7.4 User 122 8.7.4.1 User monkey 122 8.7.4.2 User farmer 123 8.7.4.3 User hacker 123 8.8 BY FAULT TYPE 123 8.8.1 A word on the fault model 123 8.8.2 Boundary conditions 124 8.8.3 Arithmetic overflows 125 13

14 8.8.4 Buffer overflows 126 8.8.5 Race conditions 127 8.8.6 Uninitialized variables 129 8.8.7 Uncaught exceptions 130 8.8.8 Resource allocation 130 8.8.9 That s not all again 130 9 QUALITY OF TESTING 131 9.1 HUH? 131 9.2 CODE COVERAGE 131 9.3 SOFTWARE METRICS 132 9.4 TEST PLAN REVIEW 133 9.5 SEEDING BUGS AND CODE MUTATION 134 9.6 TESTABILITY 134 9.7 BETA RELEASE/BETA TESTING 136 10 POST-RELEASE FUN 138 10.1 DEPLOYMENT TESTING 139 10.2 COMPATIBILITY TESTING 139 10.3 SYSTEM TESTING 139 10.4 STAGING AND PRODUCTION ENVIRONMENT 140 11 TESTING SOFTWARE IN A GLOBAL TEAM 141 11.1 TECHNICALLY SPEAKING 141 11.2 HUMAN-ORIENTED 142 11.2.1 Time zone differences. 142 11.2.2 Work relations and cultural differences 142 11.2.3 Life in a global org 143 12 SURVIVING AS A TESTER 145 12.1 FUZZY VALUE IN THE SOFTWARE DEVELOPMENT_ 145 12.2 COST/VALUE BALANCE 146 12.3 RELIGIONS AND CONFESSIONS 147 12.4 IEEE ROLE 151 12.5 OFFICE POLITICS 151 12.6 OUTSOURCING AND JOB SECURITY 154 12.7 SEGREGATION 157 12.8 FUTURE OF THE TRADE 158 12.8.1 From nobility to peasants 158

12.8.2 Crushing craftsmen 161 12.8.3 Assault on software development 162 12.8.4 What s next? 165 13 APPENDIX A. TEST CASE 168 14 APPENDIX B. BIBLIOGRAPHY 170 14.1 STANDARDS AND CLASSICS 170 14.2 EXTREME TESTING & RELATED 171 14.3 OTHER 172 15 ENDNOTES 174 15