I usually mention that the work I do as a test manager is more around managing the testing activity, than managing testing specialists. “Managing the testing activity” to me is about:
- Identifying the expectations are around the testing activities
- Facilitating the performance/execution of the testing activities
- Administration and documentation of the testing activity
- Make the people doing the testing self-reliant
… in Context
The project context is the most important frame: it is all about the projects
story, risk profile, culture, traditions, deadline, budget etc. I am as Context-driven as contexts allow, in the classical “Seven Basic Principles of the Context-Driven School” sense*.
As I am motivated by finding solutions and making them work** my drive is more along the lines of “accelerate the achievement of shippable quality” [Modern Testing Mission] than “finding the problems that threaten the value of the product” [Rapid Software Testing].
Focussing on achievements over problems seems to work for me in the contexts I’m in, regarding enterprise transition, infrastructure projects and the implementation of commercial standard systems.
Setting a Frame for Expectations
Finding the “test solution” (or test strategy) that fits the project context is the key activity to me. The rest of it, is mostly about implementation – that too can be quite interesting. I like that too, but plan first!
First of all we have to realize that the testing activities we choose are limited and affected by or context (and biases). We can never test everything and think of everything to test. Based on the context restrictions (time, space, money, etc) the project gives me, I make a reduction of the testing theories and principles into a definition along the lines of:
In a specific context – testing will be a finite activity, to investigate if the shared interpretations of the requirements are implemented – at some time, for some configuration, evaluated by someone (that we trust), where nothing odd happens.
A reduction of the testing activity
Let me be the first to say: It’s not theoretical perfect! But it’s practical and based on context. The reduction gives me an achievable goal-oriented focus. It helps me to iron out what the relation is between the thing under test and someone whom it matters to.
Ironing out the Expectations
If there is an underlying risk that things will change a lot, then we can argue for test automation to multiply the configurations and the number of “runs” we can complete. Not all IT projects are around software development, so test automation practices and tooling might not be in place.
We can ask Open Questions to explore the boundaries of the shared understanding. We can discuss: how much total test coverage is needed here? We can challenge the requests for the kitchen sink – but also direct the testing to what matters. I have found that it is better to slowly impact the projects with questions from within, as discussed on the Guilty Tester Podcast, than break down traditions up front. We can look into “who” is doing the investigation and how much we trust them.
To make the agreements around the reduction of the testing activity explicit I establish a “Test Plan” document. I would often prefer to do without, and have a mutual team agreement – or even a mind map. But I know the enterprise contexts, too well to know, that shared expectations are best written down (even though it being an imperfective as well).
It’s all about the context and the expectations, really.
*: Even “CDT” is a context/model, and thus is flawed. One of the flaws of the model is that all test approaches are equally valid (as long as it adds value to someone who matters) and thus that no approach is never better than any other. Not even CDT..
**: See: Innovation in Testing, Less Software more Testing.
Complexity is a Matter of Perspective 