1. Putting Experience to the test
Moving from Tech Comm to Software Testing
Putting Experience to the test
Raymond Gillespie TCUK15

2. Software testing Can technical communicators become testers?
What can Tech Comm learn from Software Testing?

3. What is testing?
“…testing is the process of comparing ‘what is’ with ‘what ought to be.’…” Lee Copeland
Copeland, L. (2004) A Practitioner’s Guide to Software Test Design, Artech House Publishing, MA

4. Dynamic vs static testing
Static analysis of code using tools
Static testing
Without execution of software
With execution of software
Dynamic
testing
Reviews

5. Objectives Finding defects Gaining confidence Decision making
Preventing defects

6. Test levels

7. Change-related testing
Test Types
Blackbox
testing
Non-functional
testing
Whitebox
testing
Confirmation
Change-related testing
Regression 7

8. White-box testing
Software Under Test

9. Example: Airline ticket issuing system6
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.

10. Black-box testing
Software Under Test

11. Can a technical communicator become an effective software tester?
‘Black-box’ functional testing
Test design methods
Test management processes
Test tools

12. What can a technical communicator learn from software testing?
#1 presence of faults
#7 Absence of errors fallacy
#2 Exhaustive testing impossible
7 principles
#6 Testing is context dependent
#3 Early testing is good
#4 Defects occur in clusters
#5 Pesticide paradox

13. #1 Presence of faults

14. #2 Exhaustive testing is impossible

15. #3 Early testing is good

16. #4 Defect clustering

17. #5 The pesticide paradox

18. #6 The Testing context

19. #7 Absence of errors fallacy

20. Can the 7 principles be applied to documentation?

21. #1 Presence of faults

22. #2 Exhaustive testing is impossible

23. #3 Early testing is good

24. #4 Defect clustering

25. #5 The pesticide paradox

26. #6 The Testing context

27. #7 Absence of errors fallacy

28. The ‘oracle problem’
What are the correct results?
Software Under Test

29. Summing up

30. Any questions?

31. Thanks for your time!