Mindset of a (Ninja) Tester

Vaido Vähk

Who is a tester

Testers break stuff

And the Developers be like ...

If we break anything it's ...

I’m a research scientist.• My field of study is a product that’s in development. • I research the product and everything around it to discover things that no one else has noticed so

far. • An important focus of my research is potential problems that threaten the value of the product. • Other people—builders and managers—may know an immense amount about the product, but the

majority of their attention is necessarily directed towards trying to make things work, and satisfaction about things that appear to work already. • As a scientist, I’m attempting to falsify the theory that everything is okay with the product. • So I study the technologies on which the product is built. • I model the tasks and the problem space that the product is intended to address. • I analyze each feature in the product, looking for problems in the way it was designed. • I experiment with each part of the product, trying to disprove the theory that it will behave

reasonably no matter what people throw at it. • I recognize the difference between an experiment (investigating whether something works) and a

demonstration (showing that something can work).

By Michael Bolton

A good tester tries to walk in end-user's shoes...

… all of them

Why a user MIGHT do that..• The user was distracted by something, and happened to omit an

important step from a normal process.• The user was poorly trained in how to use the product.• The user was curious, and was trying to learn about the system.• The user was in another country, where they use commas instead of

periods, dashes instead of slashes, kilometres instead of miles… Or where dates aren’t rendered the way we render them here• The user was a hacker, and wanted to find specific vulnerabilities in the

system.Etc.

...the toilet story...

There is no best practices, however...

...heuristics !!!

I Sliced Up Fun• I – Input. • S – Store. • L – Location. • I – Interactions/Interruptions. • C – Communication. • E – Ergonomics. • D – Data. • U – Usability. • P – Platform. • F – Function. • U – User scenarios. • N – Network.

More on subject:• http://www.developsense.com/ - Michael Bolton• http://www.satisfice.com/ - James Bach• "Lessons Learned in Software Testing" - Cem Kaner

… panel discussion ideas and questions!