Testing: It’s largely about the mindset, isn’t it?

I was sat on the train to the recent SIGIST and I got thinking about what a colleague had told me about James Whittaker’s talk at Eurostar on the topic of Exploratory Testing and how Microsoft are trialling this Exploratory Tour idea. The idea, I think, is fantastic and I understand that James is writing a book which will cover the tours in detail and so, rather than talking about these I want to use this blog to look at how I took the concept, and applied it to the nearest thing I had that very morning when travelling to SIGIST, the train…

To recap, James Whittaker of Microsoft looked at using tour analogies to focus their Exploratory Testing and having reflected on this idea it seems to be very much about the mindset with which the tester adopts when designing or executing tests and ultimately, it doesn’t matter whether he or she is doing ET, some form of prescriptive test or an automated test – the mindset is still important and can be consistent across all forms of testing.

So, how can the mindset, or approach to some testing be linked directly with trains? Well, here’s what I came up with (and this was at 7.15am so I make no apologies if it’s complete tosh):

• The fast train tour: Take the quickest / shortest route through the program
• The slow train tour: Stop and observe (test?) each point in the program
• The Bullet Train tour: Review each function for performance; how quickly does this program perform?
• The Flying Scotsman tour: See the heuristic oracle, “consistent with previous product”
• The Rush hour tour: Apply lots of data / input at every opportunity (stress / load testing?)
• The Viaduct tour: High level view of the system, what might a customer’s first impressions of this product be?
• The Underground tour: Look at the program from a lower level; focus on data, the code…
• The Rotate train tour (I don't know what these are called!): Ensure a consistent change of direction, maybe through testing navigation, whilst testing the program
• The Signal Point tour: Test for correct instruction / messaging from the application
• The Impatient Commuter tour: test for any unexpected delays in operation, possibly whilst performing the fast train tour
• The Packed Station Tour: Get lots of users using the program, how does it react? How good is the information provided to different users? How do they perceive the usefulness of the information provided?

Irrespective of the use of the tours I believe this would aid consideration for different types of tests, again, different mindsets required to test an application. They’re almost heuristics, I guess…
Can you think of any more? How can you use this type of thinking to inspire thought around tests?

Final note; this is an expansion of James Whittaker / Microsoft’s idea and I merely wish to expand, not take credit, for this type of thinking…