Seven Questions

This is the opening blog of a small series of posts in which I elaborate on a test approach heuristic using 7 questions that I have developed over the years.

Thinking about testing

As a tester I have seen many approaches to software testing pass me by. A few of them, like TMap (Next) and ISTQB were picked up by the Rabobank and I have had the mixed pleasure of working with them. But regardless of how different the approaches voice out to be from each other they all seem to have a number of things in common:

  • They are mostly oriented on management (of testing)
  • They focus on processes and deliverables
  • They do not teach you how to actually test something in practice
  • They hardly make any connection to software development in general
  • They are supposedly mastered after certification

I admit that both TMap and ISTQB (initially) helped to give testing a positive foothold in many organisations and have underlined that testing should get its place in software development. Even so the five elements I have described above should also show that there are fundamental flaws in how these approaches apply testing. Following them does not guarantee you to get fully involved into software development nor does it teach you how to test in practice. Usually as a compensation for these flaws testers go to boot camp like courses to teach them more practical testing skills, like determining test coverage and applying test design techniques. Even so for many testers the start-up of their professional life is focused on getting the certification and maybe some introduction to actual testing. And then….well…..for of them most it ends here and they go out to work and follow the processes and deliver a bunch of documents. If your new to software testing this will probably keep you busy for a while, but eventually you (should) start to ask yourself questions like: Is there no better way to test this? Do I really have to write these elaborate test plans / test scripts / test cases that nobody seems to really care about? Why don’t the developers agree with me on my defects? Why is my work not valued?

I have asked myself these and similar questions and over the years I have come up with a set of alternative questions whose answers guide me through a development / test cycle. These questions demand creativity, knowledge and skilled experience to answer them. And any answer you can come up with this time will differ the next time you ask yourself that same question again.

The seven questions I use are:

I have done a talk on these seven questions at EuroSTAR 2012 and will do the at Belgium Testing Days 2013. Contact me there if you want to meet and talk, or sent me a tweet @arborosa .

Here are some twitter reactions that I got from talking at EuroSTAR 2012

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

A footnote on the future

A while ago I wrote a post called ‘Is testing dead?‘ in which I reacted to Alberto Savoia’s and James Whittaker’s Test is dead paradigm. In short the paradigm stated that testing is changing and will move into two directions. Either it will move down to the developers or it will move up to the users. And at this time I still do not agree with the idea that the software testing craft will disappear. I do however agree that software testing is changing. And I see two characteristics, that are not often mentioned as such, driving the change.

Testing is not a goal in itself

and

Software development is a form of communication

This post will address the first characteristic. A following post will address the second characteristic.

Let me repeat the first characteristic “testing is not a goal in itself“. The reason I emphasize this is that to me it seems that a lot of discussion and activity surrounding software testing ignores the most obvious thing of all.

Testing software is one of many activities you do

while developing software

I imagine that reading this you may think “Yeah right, that’s indeed stating the obvious”.  But look again and note that there is something odd about this sentence if you consider the (still) dominant way to approach software testing. First of all I switched software testing to testing software. The reason I do this is because to me software testing refers to the craft, the skills, the ideas, the learning and the process of testing software. Whereas testing software refers to the actual act of bringing the craftsmanship, skills and ideas into action within a project and as part of a team. Secondly I believe that good software testing can only exist if executed in collaboration and alignment with the whole team and only if it is directed towards delivering a valuable solution to the stakeholder(s). With this I assign an equal value to all activities (architecture, coding, testing, managing, facilitating, etc.) during software development. I believe that all of these activities and their roles are needed to develop software and that they will only vary over time based on either contextual demands or limitations.

The above is in contrast with the still present ‘mainstream’ way of looking upon software testing. Software testing is often still seen as a separate activity performed independently by a (almost) isolated tester or test group. Even in agile software testers are often still seen as separate by the team. Or probably worse testers see themselves as having a separate responsibility to guarantee quality.

In addition most courses that involve software testing address software testing as if it were a stand alone activity. In this isolation they explain how to execute tests, how to make the testing process better or how to influence the other roles to follow testing principles.

In my opinion both testing education and testing practice should remove their blinkers and realize that testing software, even if it is an important activity, is only one of the activities in software development. Software testers have to learn to be team players. They have to learn to collaborate with all roles. The have to learn to integrate testing into the process of software development. They have to learn to do this while still advancing their craft and skills as a software tester. Because even if integrated software testing still is a specialism. It just is not a specialism for its own sake it is a specialism within a team and in service of delivering a valuable product.

The second post in this series will go into how I think testers should do this.