In this podcast I discuss a UK government guidance document on exploratory testing.
NOTE: this is not a transcript, there is additional information in the audio and video.
n this episode we have a discussion of a UK government guide to exploratory testing.
The aim is not to criticise the document, the aim is to use it as a base from which to see how far our thoughts diverge or overlap with the document. I want to know what I can learn.
This podcast, was originally released to Patreon supporters in January of 2019,
I read through the document and try to understand the intent and meaning behind statements and offer my own thoughts.
The fact that I’m reading a document sounds like this should be visual, and there is a video version, but all the points in the document I read aloud so you can think through the points as you hear them in the audio.
And the reason for releasing this is to encourage people to build your own opinions about other people’s work, and accept them as an alternative point of view. We don’t have to have a binary True / False world. People are allowed to have their own opinions. And they do have their own opinions. Our job is to have our own opinions, that we have though through, and can justify, so if we need to discuss them, we are in a position to do so.
And that is what I’m ultimately trying to do here, and fortunately it is a document about exploratory testing which I have a lot of experience doing, so I have opinions.
- the written word is someone’s attempt to explain their thinking
- I very often do not explore the system as a user would
- I very often use technical tools to help me get under the covers
- Ambiguity means we have to interpret what someone else says or writes
- Exploratory Testing can be done to look for very specific ’things’ - risks, events, defects, data, etc.
- I use exploratory testing to find information that allows me to expand my model.
- words that I expect to see associated with exploratory testing: Discovery, exploration, new, information.
- not necessarily user oriented
- sometimes the logging notion of time is very useful for testing.
- Setting a limit is useful because all testing is essentially unbounded.
- Good notes are massively important.
- on an agile project you’re very often testing on a story by story basis. You’ve got a much smaller set of criteria.
- I rarely use pen and paper I normally use a text editor… because my writing is unreadable After a while.
