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.