DEWT2 - Becoming a context-driven tester

About a month ago ago (October 5th - 6th) I was in Driebergen to attend DEWT2, a peer workshop with as theme “Implementing Context-Driven Testing”. As it turns out, implementing context-driven testing is not easy to do. That should not come as a surprise: it requires people to change and that is difficult. Luckily, I’m not a manager wanting to implement context-driven testing, so I can dodge most of that problem.

However, I do like ‘spreading the word’ on context-driven testing, because I would like for there to be more context-driven testers in the Netherlands (and Europe and the world, of course). So to promote context-driven testing I think there are three things I can do:
1) set an example,
2) be available to other people,
3) leave bread crumbs.

Setting an example means testing in a context-driven way and (very important) labelling it as such. You want people to know there’s a reason you do the things you do and that reason has a name: context-driven testing.
Secondly, be available to people. When asked a question, don’t just answer the question. Take your time to engage in a conversation.
Finally, leave bread crumbs to expose other people to context-driven testing. Keep some books on your desk. Put the 37 test ideas from the Little Black Book on Test Design up on a wall. Or a mindmap with the test coverage of your current project. Perhaps no one will ask about it, but perhaps someone will.

Now, I am fully aware these three things are nothing special. They are not the result of a stroke of genius insight on my part, if only because they were very much present in the talks by the speakers (Henrik Ilari Aegerter, Markus Gärtner, Ray Oei, Ruud Cox and Huib Schoots) and in the discussions at DEWT2.

However, I now am wondering perhaps there isn’t much more we can do, because (as I said earlier) change is hard. As I have discovered in one of my other pursuits: some people will get it and some people won’t. If you’re for instance a factory school-tester, you may become intrigued by the context-driven school or you may not. You may come to prefer the context-driven school or not. You may be able to fully change to a context-driven way of thinking or not. So there are at least three points in time in which a person may ‘fail’ to become an actual context-driven tester.

And even if you are able to make the change, it will take quite some time to make the change. Perhaps I’m not at all representative, but to illustrate here’s how I became a context-driven tester.

How I became a context-driven tester

My career in testing started in May 2006 with a TMap course and I got the ‘Professional Advanced’ certificate in June 2007. Somewhere in 2008 I started teaching this TMap course to our new employees. So let’s say I had a fair grasp of TMap and thus (unknowingly) of the factory school of testing.

Then, somewhere in the beginning of 2010 I came across the blogs of James Bach and Michael Bolton, so I read those from the first post to the most recent. I also read the Rapid Software Testing course slides. I read about the different schools in software testing. I read “Lessons Learned In Software Testing” and read the context-driven-testin.com site. Did this make me context-driven tester? No, I was just a guy that had read a lot about it. I liked what I read, but I did not really actually get it.

In November 2010 I attended the Rapid Software Testing class taught by Michael Bolton in London. This did give me a better grasp of what a context-driven testing approach looked like, but afterwards I still didn’t feel I was a context-driven tester. It still felt somewhat alien to me. So I continued to process everything. I noticed that quite often the first response to a situation that came into my mind was a factory-style one, but if I put a little more tought in it, I could also provide a ‘proper’ context-driven answer. In that respect thid was a very strange phase: noticing factory school thoughts popping up in my mind and then having a different part of my mind reasoning against those thoughts with context-driven arguments.

Fast forward to Januari 2012 when I began this blog. I even did a few posts on the seven principles of context-driven testing and still I didn’t feel like I was a context-driven tester. May 2012 I was at the Let’s Test conference in Sweden; that helped. And then finally in July 2012 I made my first blog post on the VIPT model and felt I had become a context-driven tester - probably because that model is my personal synthesis of context-driven testing. Only since that moment do I feel like context-driven testing is a fundamental part of how I think about testing.

So to summarize I went through these three stages:
1) Being interested and absorbing information;
2) Being able to reason to a context-driven repsonse;
3) Being a context-driven tester.

And it took me about 2.5 years to go through these three stages. To be honest, I don’t think that’s slow. Changing the way you look at testing in a fundamental way takes time. And the longer ago you made that change, the harder it is to remember how you thought before the change and to remember how you made this change. Which is part of the reason I am writing this blog post: to document this while I still remember. Because in a few years time I will have as hard a time to imagine what it’s like to think factory school as I had all those years ago imagining there was a different way to think about testing.

This post was originally published here.