This document outlines Alan Richardson's webinar on technical testing. It discusses why technical testing is important given increasing technical complexity. It describes what technical testing entails, such as understanding databases and code. The document provides examples of technical testing concepts like boundary value analysis. It also discusses how to identify technical testing and what barriers may exist, emphasizing personal motivation. Finally, it suggests that with the right approach, anyone can learn technical testing and offers resources for further reading.

1. The Evil Tester's Guide to
Technical Testing
Eurostar Webinar 4th December 2012
Alan Richardson
www.eviltester.com
www.compendiumdev.co.uk
www.seleniumsimplified.com
@eviltester

2. Warning: This Webinar contains
Opinions.
● Why should you care?
● How to spot Technical Testing?
● What stops Technical Testing?
● Test Techniques Revisited
● How a technical tester views a system
● Can anyone do this?
● The bluffer's guide to technical testing

3. Why Should you care?

4. Why should you care?
"Technical Testing sounds like hard work and I
can get away without doing this stuff."

5. Reasons Based on FEAR
● Projects are becoming more technical
● "They" are now testing

6. Reasons based on HOPE
● Flexibility
● Find different types of bugs faster
● Find bugs faster
● Add more value
● Future proof yourself

7. What IS
Technical Testing?

8. I don't know...
...But I do know:
● Technical knowledge transfers between
domains
● Testing != Technical

9. And I know it when I see it...
So let's play...
The
"Is it Technical Testing?"
Game

10. "Do you look in the Database?"
If you say...
"I don't look at the database that's not my job."
Are you doing
Technical Testing?

11. NO - wrong attitude

12. "Do you look in the Database?"
If you say...
"Of course I look in the database, I run these
queries that the developers gave me"
Are you doing
Technical Testing?

13. No - Not enough Understanding

14. "Do you look in the Database?"
If you say...
"Yes, I use the default admin tool, I run custom
queries before and after I use the app, to check
results. I understand the DB schema pretty
well."
Are you doing
Technical Testing?

15. Yes - with more to learn

16. "Do you look in the Database?"
If you say...
"Of course, and I sometimes ssh in, I never use
the default tool, I prefer DBToolX. I have a
script that compares the schema between
releases, and yeah, I query the db to see
what's going on."
Are you doing
Technical Testing?

17. Yes - I aspire to this

18. How to spot it?
● Attitude
● Asking Questions
● Leave no stone unturned
● Tool Up
● Pairing
● Experiment
● Own It

19. Test Techniques
Revisited

20. Boundary Value Analysis
● Process a drop down with 250 items
● One technical premise: loop conditions are
tricky
boolean foundit=false;
for(int item=1; item<=250; item++){
if(db.isItemPresent(dropDown.get(item)){
foundit=true;
break;
}
}

21. BVA and Technical Knowledge
● What if the technical premise changes?
foundit = false;
for(Item item : dropDown.getItems()){
if(chosenItem.equals(item)){
foundit=true;
break;
}
}

22. How a Technical
Tester Views Your
Application

23. A Non-technical view of an app
Requirements Functional Non-functional
Doc Spec Requirements
http://www.compendiumdev.co.uk/selenium/search.php

24. A Technical View - Web App Terrain

25. A Technical View - Server Terrain

26. A Technical View - Browser Terrain

27. A Technical View - Architecture
Terrain

28. A Technical View - User Terrain

29. What Stops
Technical Testing?

30. What stops technical testing?
● Environment
● The Manager
● ...
● Personal Motivation

31. Environment: Lock it down
You can try to stop technical testing
by locking down the environment.

32. The Manager
"I'm a manager, I don't need to be
technical."

33. Personal Motivation...
"Will trumps everything"

34. Can Anyone do this?

35. If I can do it, anyone can do it...
... and I've seen other people do it.

36. Shh... don't tell anyone... but...
...I'm not that technical

37. I've learned some secrets...
● Ask questions
● Catalogue the technologies
○ use the default tools "Don't worry
● Copy others about breaking
○ pair and make notes things.
● Study and learn Testers are
○ on your own
supposed to
● Identify tools by modelling:
○ Observation
break things."
○ Manipulation
○ Interrogation
● Experiment
● Keep Learning

38. If I can do it, anyone can do it...
... and I've seen other people do it.

39. Bluffer's Guide to
Technical Testing

40. A Bluffer's Guide to Technical Web
Testing - starter for 13

41. Further Reading
● The OWASP Testing Guide
○ http://www.owasp.org/index.php/OWASP_Testing_Project
● Putting Systems to Work by Derek Hitchins
○ http://www.hitchins.net/SysBooks.html (free download pdf)
● The Art of War by Sun Tzu
○ provides a generalisable model for technical testing - including
map/territory, observation (use of spies) and manipulation
○ www.sonshi.com
○ http://www.feedbooks.com/book/168/the-art-of-war
● The Book of Five Rings by Miyamoto Musashi
○ How to practice and improve
○ http://www.feedbooks.com/book/3953/the-book-of-five-rings

42. Next up: You
Alan Richardson
@eviltester
eviltester.com
compendiumdev.co.uk
seleniumsimplified.com