If you can't read please download the document
Upload
geraldine-davidson
View
220
Download
0
Embed Size (px)
DESCRIPTION
Software testing Can technical communicators become testers? What can Tech Comm learn from Software Testing?
Citation preview
Putting Experience to the test
Moving from Tech Comm to Software Testing Putting Experience to the
test Raymond Gillespie TCUK15 Software testing Can technical
communicators become testers?
What can Tech Comm learn from Software Testing? What is testing?
testing is the process of comparing what is with what ought to be.
Lee Copeland Copeland, L. (2004) A Practitioners Guide to Software
Test Design, Artech House Publishing, MA Dynamic vs static
testing
Static analysis of code using tools Static testing Without
execution of software With execution of software Dynamic testing
Reviews Objectives Finding defects Gaining confidence Decision
making
Preventing defects Test levels Change-related testing
Test Types Blackbox testing Non-functional testing Whitebox testing
Confirmation Change-related testing Regression 7 White-box testing
Software Under Test Example: Airline ticket issuing system
6 Test Case: Non-gold-card holder on full flight 1 Gold card? Gold
card? Economy full? Economy full? N Y Y N Business class full?
Business class full? 8 2 Y 7 Business class full? Economy Y 3 N 9
Economy N Upgrade 4 Upgrade 10 Bump off flight Bump off flight 5
Boarding card Example from: Black, Rex, Erik Van Veenendaal,
Dorothy Graham (2011) Foundations of Software Testing Cengage
Learning, Andover, UK. Black-box testing Software Under Test Can a
technical communicator become an effective software tester?
Black-box functional testing Test design methods Test management
processes Test tools What can a technical communicator learn from
software testing?
#1 presence of faults #7 Absence of errors fallacy #2 Exhaustive
testing impossible 7principles #6 Testing is context dependent #3
Early testing is good #4 Defects occur in clusters #5 Pesticide
paradox #1 Presence of faults #2 Exhaustive testing is impossible
#3 Early testing is good #4 Defect clustering #5 The pesticide
paradox #6 The Testing context #7 Absence of errors fallacy Can the
7 principles be applied to documentation? #1 Presence of faults #2
Exhaustive testing is impossible #3 Early testing is good #4 Defect
clustering #5 The pesticide paradox #6 The Testing context #7
Absence of errorsfallacy The oracle problem What are the correct
results? Software Under Test Summing up Any questions? Thanks for
your time!