A couple of weeks ago I was fortunate enough to find the time to attend Michael Bolton’s webinar entitled a New agile ecosystem or “The (REAL) agile testing quadrants” as we believe it should have been”.
Disclaimer: the images are screen prints of the webinar. The link is above. I say the odd opinion myself but generally I tried to convey my understanding of the webinar.
He started with a quick mention that this talk was not an attack on agile testing or the role of a tester in an agile environment as in principle “agile development is humanist and cool!”
I think this was important for him to mention as the context driven school of testing can appear quite aggressive in expressing their opinions and thoughts on other testing schools of thought. I am unsure if this has well expressed by myself but this is just how it has appeared to me.
Anyway Michael points testing is learning how to do difficult things – increase understanding of the product and its context of working and is a central part of the development process. With this in mind he states that the original testing quadrants are unhelpful and misleading, to an extent.
What is the role of testing?
But before the webinar explored this we had to think about “what is the role of testing?”.
“Learning through exploration and experimentation.”
This means that scripted testing and exploratory testing are not opposites but rather scripted testing is a means of exploratory testing.
A tester’s role then is the prepare for testing, perform testing and report on the results of testing.
Meaning and history of “testing”
Testing has had a misunderstood meaning around quality policing. Michael adds that quality policing adds responsibility without authority.
Hence adding unnecessary distractions to the testing process.
Instead of policing quality testers add value by adding knowledge about the product and awareness of risk.
This, he explains, is a really challenging skill – hence adding things to it dilutes the testing effort overall.
We as testers help our “client” look good and this effort requires a lot of critical thinking.
Testing Skills
Michael moved onto the skills of a tester briefly and explains that curiosity is not a skill but rather a tester should have “model skills” and observe and connect the dots. “Model skills” were mentioned around being able to visualise and model a testing journey, be that the data needed or how the system is built up in your mind’s eye.
Other skills mentioned were:
- generate ideas
- define risk and problems
- elaborate – refine and communicate
- good reporting skills
- illustrating and describing issues and products
Hence policing is a distraction of the goal of testing. As testers we are most helpful when we perform testing.
Should testers only look for bugs?
“A role is a heuristic not a prison”
To say testers only find bugs would be the same as to state that developers are terrible testers.
Actually they are also testing all time and can actually be very good.
Testing involves thought experiments – try things – model – conjecture – model, etc. which are inherent to the development process.
But of course developers are not perfect testers – you still have to develop certain other skills to become a great tester.
Hard to wear two hats at once
“Testing focuses on the task of finding problems that threaten value”
Michael starts the last third of the webinar with bringing this all together to talk about the original quadrants and how they feed a misrepresentation. It is easy to read into the original quadrants in my option also, that they favour automation, checking, over actual testing.
He believes tester should be at the centre of testing and not the tools – critical thinking over automation.
Time for an overhaul – evolution
Supporting the team and critiquing the product should not be a separate seemingly opposing quadrants.
You can read an opposition around automation and manual testing, but automation is not something that you do but something you use as a tool.
Tools or hands are info-mechanisms that provide information. We need to think in terms of testing and how tools can be supportive of the testing effort.
He goes on to say that the notion of testing should be in all quadrants.
Why are certain things in certain quadrants? It should be one big testing effort. Polarities only serve to convolute the effort and distract from the actual testing.
His main criticism was that critiquing seems to not be part of programming and supporting the team implies if testers do not write code they should not be in the agile team.
Michael sees a confusing and unnecessary distinction. And provides his own solution.
Example of a generic diversified test strategy
Quadrants inside of each other – building up the effort instead of opposing actions.
Testing is an active thought process and automatic checking is inside of this but it is not music, which it appeared to be in the original version of the agile testing quadrants.
Testing as an activity cannot be read
Representations can be read but business people don’t read cod.
Testing is to develop the vision of the product and help refine the design.
Prepare for testing and do deep testing – understand the product and make information about the product accessible to the team.
When are we done? Definitions?
Things need to be re-evaluated on the basis of new information
There is more than just one human user – api, browser – he uses a broad interpretation of “user”. I actually really like thinking of a “user” meaning more than just human interaction. It has helped me with our new approach to creating a service orientated architecture which often requires services that do not have a front end.
As 100% testing is not possible we as testers need to recognise how we may not be done. This he states relates to many perspectives and from many different perspectives.
He points out a shift in adaptability in testing and not just repeatability, which automation aims for.
And maybe more importantly apply this adaptability approach to the product and can the product respond appropriately?
Development is not linear – activities tend to overlap and swirl in big and small loops.
Agile testing is testing in an agile context
We therefore need productive polarities, and not opposing ones.
He finishes with that testing benefits from a diverse perspective – critical distance is the difference between one perspective and another.
Did you enjoy the webinar?
Do you agree with the view on the original testing quadrants?
Have you got the new agile testing book “More Agile Testing”? I have just ordered it and looking forward to read it. Let me know what you think!
punkmiktests 