DEWT 2 – Drinks, dinner, more drinks and lots and lots of talk (a.k.a. day 1)

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).

Standing left to right:
Ray Oei, Jean-Paul Varwijk, Adrian Canlon, Markus Gartner (Germany), Ruud Cox, Joris Meerts, Pascal Dufour, Philip Hoeben, Gerard Drijfhout, Bryan Bakker, Derk Jan de Grood, Joep Schuurkes, Lilian Nijboer, Philip-Jan Bosch, Jeroen Rosink, Jeanne Hofmans
Kneeling left to right:
Tony Bruce (UK), Zeger van Hese (Belgium), Ilari Henrik Aegerter (Switserland), Huib Schoots, Peter Simon Schrijver

Advertisements

Endorsement

One on one

A couple of days ago I was in one of those meetings with my manager where we discuss one on one how things are going and we if we have questions or problems in which we can help each other. Since things are going well enough we mostly spent time talking about work in general, project progress and personal interests. At the end of this particular meeting my manager asked me a surprising question:

“Why do you call yourself a senior test analyst?”

I fell silent for a moment. Officially my job title states Test Analyst C so he had a point there. My response held several aspects. First of all my official job title doesn’t have any meaning outside of the office and I am often meeting or interviewing people from outside of work. So I feel more comfortable calling my self senior test analyst then.

“Okay, I understand the test analyst part, but why senior” he responded

Well, I stated, because I believe that I am senior based both on my amount of experience,  skill and the effort I put in to my work. And using this title makes it easy to recognize what I do and at which level I am.

“I see” he said “But don’t you think that others can see that you are senior based on what you say and what you do and mean to our community and to the test community in general?” “Nobody calls themselves junior or medior. I only see people using senior. So why don’t you think about why you use it and if you really need it.”

Does it matter?

Well he got me thinking. Last year I published a series of three posts, https://arborosa.org/2011/08/17/whats-in-a-name-part-3/, on using names and titles. Part of the message in these posts is that the title you carry influences how others perceive your work, but also that it influences how you perceive and execute your work yourself. I ended the last post with the following remark:

“Currently I like to think of myself as a, context driven, software testing craftsman. At what level of craftsmanship I am I leave for others to judge.” 

Even my personal business card states me to be “Software Tester”. So why did I start using Senior Test Analyst when I talk about myself?

Having thought about it has me come to the following. It is not that I feel under-appreciated at work (although I wouldn’t mind a pay rise;) nor that I feel the need to emphasize my level of ability or knowledge. It is more my perception of how non testers value the profession. And for some reason adding the senior in front of test analyst seems to add some level of authority and importance.

How about you?

It is my opinion that I am not the only one who feels that (good) testers, by what ever name they go, do not get the appreciation they deserve. So my question to you is:

What do you do to convince non testers of the importance, skill and effort that go into your job? Or do you think that it’s all their problem?