Bolton's New Agile Testing Ecosystem
I often make reference to the Agile Quadrants model to help explain different modes of testing, and how automation is just a part of a larger domain of testing.
“Essentially, all models are wrong, but some are useful”
- George E. P. Box
Firstly, a new definition is given for Testing and Tester as follows:
The Act of Testing
To test is to evaluate a product by learning about it through exploration and experimentation.
I really like this definition: it is simple, clean, and clear. It is not prescriptive on means to achieve “testing” and thus can be applied to each of the schools of testing.
The Role of Tester
A tester’s role is to develop themselves as a tester, connect with clients of testing, prepare for testing, perform testing, and report results of testing.
I agree with the message here, but feel that there is room to improve the message…
“… connect with clients of testing…”
That applies to all roles, if you switch out the last word. “ clients of development” in software, or “clients of dresses” for fashion. Does it add clarity or value to the role’s definition? The same concern applies for the next items in the sentence. In true mathematical fashion, it could be reborn as such:
f(x) = “ A x’s role is to develop themselves as a x, to connect with clients of x, prepare and perform x, and provide outputs of doing x.”
Given: x is a professional role. E.g. “Shoe Maker”, “Software Tester”, “Insurer”.
Is it just that all job roles fundamentally are similar when looked at from high enough? Is there salient differences specific to software testing that are of value to elucidate in creating a different definition of the role?
Based on the ideas expressed verbally in the presentation, the list of skills for the tester role show the nuances and intesting aspects of the role: awareness of mental heuristics (that help and hinder), ideation, risk evaluation, researching, modelling, reporting, communicating, … and many more. Bolton also expresses that there are a set of tasks and skills that he feels do not belong under the tester role: quality policing and quality improving.
I am not sure on what would make for a better role definition, and will need to think further on this topic.
Roles are not Prisons
Excellent advice with easy to grasp analogies. The reasoning provided here well align with agile methods.
Can members of agile teams can do multiple roles? Yes, and there remains value in specializations, so that individuals can become more efficient and proficient at a few roles.
The Quadrants Revisited
Bolton points out that having Manual vs. Automated in the quadrants is disingenuous. Testing is a human activity, while automation is just a tool that can be used to facilitate testing. Testing is not two composed of two flavors; all testing is manual, even reading reports from automation and making rational choices on what to do with the information it provides.
“We don’t think of a developer using a compiler as doing automated programming.” - M. Bolton
From there, he lists the cycle of agile development (though, like all theories, reality is less procedural):
- Discover: Something worth building
- Build: Some of it
- Refactor: To enable future change
- Study: The current “end result”
- … Repeat !
He makes many interesting observations about the role of testing, and the multifaceted job of a tester within this cycle, pointing out some key polarities:
- Analyzing vs. creating the product
- Trading value to customer vs. cost to develop
- Focusing on the success vs. risks to the product
That last point is raised as a central character difference between the tester and developer role; the builder mindset focuses on the paths to success while the tester mindset is focused on finding risks.
As always, I am impressed by the level of healthy dialogue, introspection, and retrospection in the testing community helping drive itself forward. Willingness to challenge past conclusions and exposing ideas for community reflection is a key tenet of the scientific method.
Keep being awesome.