I don’t know exactly when I got involved in test improvement for the first time, but it was way before models were introduced for it. Maybe it was even before people started calling it Test Improvement… I’m actually in testing long enough to have been involved in the pioneering stages of it and, as an author, played a part in defining the profession. What I do know is that helping people and/or organizations to get better at (software) testing still is a major motivator for me. I think it is (one of) the most rewarding jobs within the testing craft there is. That’s why I decided to start a series of blogs on test improvement to share my experiences.
MY FIRST MESSAGE
Truly helping a person and/or organization is not forcing them to do it your way. It is all about enabling them to do the best they can in their context: give them the means they can use in their situation. Wherever you put the emphasis “means they can use” has to be true. THEY have to use it, so it has to be in line with their skills, not yours. Whether they CAN use it depends on their abilities and if they are allowed to use it. I’ve worked in organizations where, due to regulations, the tests had to be designed and approved before execution (otherwise the test results were considered void and the product was not allowed to be shipped). Exploratory Testing was not considered an option by management. If people choose to USE something it’s because they think/know/feel/hope/expect/… that using it enables them to do it better, faster and/or cheaper. So the MEANS have to help them achieve what they want. In my opinion, “fit for context” says it all.
That’s also why I’m convinced that “one model to rule them all” does not apply to Test Improvement. I learned “through damage and shame” (sorry for the Dunglish) that the characteristics of each test improvement model define it’s added value. And it’s limitations. If you want to help improve testing and use a model, the improvement model has to be “fit for context”.
Keep you posted!
I promised myself to improve my blogging and share my experiences in the area of test improvement through this blog. I already started working on the next post…
Ruud Teunissen 
Hello Ruud,
Considering you once piloted the TPI Next model in my team and seemed pretty much convinced that it was the right way forward the sentences “That’s also why I’m convinced that “one model to rule them all” does not apply to Test Improvement. I learned “through damage and shame”” have some added meaning to me.
I am not sure that Context Driven Testing really is claimed by so many in the testing scene. I can imagine that the fact that some of the Context Driven testers are of the more visible than average variety would make you believe so. And of course having the TestNet Autumn event bear Context Driven as a theme adds to the perception, but I think that (unfortunately) in spite of this momentary visibility not many actually practice or claim to be Context Driven.
I think that using Context Driven Test Improvement would have been wrong for another reason. Context Driven Testing in itself aims to provide the best service on delivering valuable information about the product and the testing process by which that information was obtained. It does so by considering, acknowledging and using the context in which it is performed. It does also use new insights about the context that arise or new skills and knowledge that becomes available. So by nature it seeks to improve whenever this is possible.
Regards,
Jean-Paul
Sorry Jean-Paul, I did not pilot TPI Next at your site or team. Guess the owner of the model did that…
I did present the differences between the original and Next model though. If I’m not mistaken, I pointed out that any improvement has to be “fit for context”.
Your comment on Context Driven however does lead to an interesting question: how Context Driven are the ones that claim to be Context Driven?
Ruud