At the Ministry of Testing’s TestBash and Test.Bash() 2019 it was my pleasure to speak with people about accessibility through my quiz.
This poem was performed at Test.Bash() Manchester in their 99-second talks. This was inspired by Krissie Barrick’s talk at Accessibility Nottingham about a day in the life of a person with disabilities
A testing poem performed at TestBash Manchester 2019 and inspired by Tony Walsh’s Take This Pen
During my time at TestBash Brighton possibly the most common subject to pop up was related to group testing activities. Be that mobbing, bug bashes or whole team test days built into the process. Maaike Brinkhof in her talk, ‘Exploratory Testing with the Team, a Journey Worth Taking’ explained how they undertook ‘Team Test Sessions’ before they released.
This is the story of our first foray into testing as a team.
For my talk at TestBash Brighton Essentials (see ref below for slides and more) one of the things I covered was what I believe testing is. Over the last 6-months or so I have been mentoring a new tester on their journey and to start that journey, I had to explain what testing is.
There are a many, many attempts to explain testing and I even referenced one of my favourite descriptions in my presentation.
Testing is the infinite process of comparing the invisible to the ambiguous so as to avoid the unthinkable happening to the anonymous.
Over time, the more I looked at how different people went to great lengths to explain the craft, the techniques, the mind set and from other perspectives. I though, there must be a simpler way of beginning the conversation as it is my opinion that when trying to explain what ‘testing is…’ we do ourselves a disservice and answer instead, ‘what testers do…’ or a close variation.
My belief is when we do this, we confuse ourselves and others and we would really help our craft and each other if we simply said;
Testing is part of risk mitigation for the product or system.
Now I know that might sound overly simplistic when we are sometimes put in the position of defending our profession and craft. But, we should follow up with;
And we do that by…
This way, when we talk about critical thinking, observation, problem identification and solving; explain why automation helps but isn’t a solution in of itself; offer advice about bias, empathy and inclusion; offer opinions on observability and testability and ask unexpected questions from the, ‘but that would never happen’ category, there would be a clear concept that all these things help us identify and reduce risk for the product or system we are helping develop.
I would be really happy to hear others opinions on this way of thinking. Please let me know in the comments or follow up on Twitter @CricketRulz
Talk link to be added later, may be Pro or attendees only, to be confirmed