I was very pleased to be part of the 2nd DEWT workshop. This Peer conference took place on October 5 and 6 at Hotel Bergse Bossen in Driebergen, the Netherlands. The Dutch Exploratory Workshop on Testing (DEWT) is a workshop that falls into the series of peer workshops on testing like LAWST, LEWT, SWET and GATE. The main theme of this workshop was:

 Experience Reports: Implementing Context-Driven Testing.

Friday evening started with gathering in the grand cafe, dinner and a lightning talk by myself in the conference room. I had planned and prepared the lightning talk to be about the summarized content of my EuroSTAR conference talk “Seven Questions to Help You on the Path of Testing”.

A talk that I have also entered for the next Dutch Testing Conference. The Dutch Testing Conference has a process of sending review comments on your abstract and one of the remarks in the review, a couple of days before, made me change my mind about the lightning talk. That particular remark reminded me that the context driven approach to testing is far away from being common knowledge in the software testing world.

I wondered how we communicate our view on testing and why it is that we are not really effective in bringing the message of context driven testing across?

The section below describes what my thoughts were about the content of my lightning talk mixed and enhanced with parts of the discussions arose after the discussion and later that evening when we were having drinks and the next day during the conference.

Since I started to see myself as a follower of the context driven testing (CDT) approach I have seen many a tweet and blog pass by proclaiming that if you follow context driven testing results will be much better than if you are using the old school / traditional / factory / waterfall / IEEE/ ISTQB process approaches to testing. And roughly parallel with my start of being context driven I also started to work in an agile environment. And like CDT many agilists proclaim superiority on traditional or waterfall approaches of software development. And sure enough if applied consciously and thoughtfully both approaches often yield better results than the more process oriented ‘traditional’ approaches. But even so I believe both followers of CDT and agile are making a few fundamental mistakes in their communication.

First of all the agile manifesto and the context driven testing principles have been around for over ten years now and at that time it probably was a good idea to react against the then main stream ideas of software testing. However a lot of time has passed since then and most people who had (or still have) the same feeling towards the ‘old’ approaches have changed to following the ideas of CDT and / or agile by now. So this rhetoric will have no effect on them anymore. Well maybe it could create some kind of group identity, but that can hardly be the purpose in my opinion.

Second I wonder how many people actually work in a true traditional / waterfall assignment. Personally I admit to having worked in an environment based on so-called waterfall process principles, but even then I saw myself as being in a true waterfall assignment. And in that particular case hardly anybody fully committed to doing waterfall (or to be more specific TMap) by the book. And obviously this underlines the flaw of such process and deliverable oriented approaches, but it also shows that a lot of people in such an environment do not commit to the approach as such. So trying to sway them to follow your approach because their approach is ‘bad’ might look appealing, but kind of misses the point as a lot of people in that environment will feel you are not talking about them. And even if they feel addressed by your comments how will this make them change. For the better part they already agreed with you so what your telling is either no news or not adding helpful information.

Finally, and this is for me personally the main conclusion of the discussions. Being context driven is not about being against something. It is about being a (self) educated, thoughtful, skillful, open to your context testing craftsman. A craftsman that is likely to engage in to an open discourse with his peers and team mates, who’s drive it is to learn what is necessary to do the job and then learn some more just for the fun of it. As Joris Meerts aptly pointed out “Yes that does make us elitist.” For unfortunately there are not that may software testers that invest in maintaining or even extending their software testing (and general) skills, let alone seeking to collaborate with others while they are doing that.

Even after one and a half day of conferring the question on how to bring the context driven testing message and mindset across is still not answered. So let me know if you come up with useful ideas and I will collect them and come back to the subject on our next DEWT peer conference (or any time sooner when we meet).