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.
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.
To me, this an odd interpretation of anything I’ve ever read, heard, or thought about context-driven testing. Can you point me to a reference?
LikeLike
As there are no best practices, neither are there worst. And even ISTQB is value to someone*.
When there are no best or worst, there is no way to order/sort the practices by value.
Hence all practices are equally valid.. or valueless… without context.
Anders says it better: https://asym.dk/2018/09/17/a-stage-performance/
(Test Bash Germany 2018)
To add value to the Context-driven Principles we need personal judgement.
Joep has a piece I reference here:
https://jlottosen.wordpress.com/2012/08/27/context-driven-testing-is-personal/
* see: https://jlottosen.wordpress.com/2012/03/24/im-at-theoretically-yes-but-realistically-maybe-but-i-might-be-wrong/)
LikeLiked by 1 person
[…] the requirement workshops I will label the requirements and align with the stakeholders to get the expectations right – with the help of a few friends. This a context/project based […]
LikeLike
[…] Expectations around Testing – Jesper Ottosen – https://jlottosen.wordpress.com/2019/05/07/expectations-around-testing/ […]
LikeLike
[…] Expectations around Testing […]
LikeLike
[…] … but that was “just feelings”, he wrote in the end. And indeed it is – No matter how it looks at first, it’s always a people problem and even if we have a successful test automation effort – we can still fail to appreciate the experts knowledge and by that fail to solve the business problems. […]
LikeLike
[…] Stop focusing on the things that bug people, and dare to do both IT and testing smarter and more business focused from the start. Build Quality in – smarter from start. That goes for IT services as a whole, and definitely also for the testing activities. […]
LikeLike
[…] Expectations around Testing […]
LikeLike
[…] discuss and visualize the overall test approach. While this can be put in a test strategy document (I often do) – a test strategy is only a written narrative of the test strategy selected. Test coverage […]
LikeLike
[…] the focus of this article is visual models. From what I have seen with regards to test strategy document templates the Ashby model, below, illustrates most of the practical content in such […]
LikeLike
[…] exploration. They will never see themselves as testers, se we need to reframe their contribution, expectations and provide a space for them to grow their […]
LikeLike
[…] solution. Parts of it is always moving somewhere new. While a fixed test strategy document can help establish expectations – the visualization and communication around the strategy is the key […]
LikeLike
[…] I have previously talked about writing down expectations and alignments – I would much prefer a more lean and up-to-date approach to test plan documents. Looking at […]
LikeLike
[…] The Ministry of Testing Bloggers Club suggested that I write a post based on “In testing, I have changed my mind about ________”. As this blog dates back to 2012 with consistent (220) articles about testing, and my career in the field dates back to 2002 – it seems a 20-year experience should give me a few things. Testing is still not dead – and it’s still about the context (lower-case context, not CDT). […]
LikeLike