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


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.


What’s in a name – Part 2, I am a quality assurer

This second post on the use of titles for software testing focusses on software quality assurance. Quality assurance, or QA, as such is not exclusive to software development. QA is practised in almost every other industry like e.g. car manufacturing or medicine.

Quality Assurance

Quality Assurance in essence involves monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with according to those same standards and procedures. Quality assurance is often seen as an activity to be executed independent of its subject.


The following two principles are included in the aim of Quality Assurance:

  • Fit for purpose; the product should be suitable for its intended purpose
  • Right the first time; faults in the product should be eliminated

The guiding principle behind Quality Assurance is that quality is malleable. This is achieved by working hierarchically according to detailed plans, use accurate planning and control, rationalise processes, standardise and uniform. In this sense quality assurance is continuation of Frederick W. Taylor’s ideas of Scientific Management. In line with this all skill and knowledge is transferred into standard processes, procedures, rules and templates and thus removed from individual workers.

Software quality assurance

By and in large software quality assurance follows the same lines of thought as quality assurance.

This part of the model then represents the assurance paradigm.

Like in quality assurance a tester in software quality assurance seeks the use of rationalized processes, standards and uniformity. She prefers the use of specific standards and methodologies. IEEE, ISTQB and TMap are well know examples of this. These methods provide the tester with (seemingly) clear guidelines to follow and artifacts to use so that if used properly software testing itself should provide adequate information about the state of the product and its readiness for use.

There is however a distinct difference between software quality assurance and quality assurance . In contrast with quality assurance in the traditional sence software does not have something tangible to measure. This is partly overcome with the use of software related quality attributes. Quality attributes are used to help guide the focus of testing and consist of characteristics that are considered typical to software development.

SQA – testing

Software quality assurance has the advantage that it is an understandable and recognizable proposition. To testers the appeal is that it provides a uniform solution for “all” situations and the handbook approach can be followed from the get go. To managers the appeal is that the procedures are recognizable in relation to mainstream management ideas and in combination with a phased interpretation of software development and testing, e.g. the V-Model, it is highly useful for project planning.

Following the process and filling templates alone (even) software quality assurance admits does not produce tests. So software quality assurance has teamed up with software engineering in that it uses test design techniques to identify and describe tests. In turn software quality assurance has developed means to limit the scope of testing with using a combination of quality attributes and risk assessment to order and if necessary limit the amount of tests to be designed and/or executed.


In practise the use of software quality assurance, together with test engineering, has admittedly helped to establish software testing as a craft of its own. It has put software testing on the map and in general software testing is seen as part of the development process. But the use of software quality assurance as such has been no guarantee in stopping the development of ‘bad’ software. With bad software I mean software that did not provide a solution for the problem it was intended for.

In response to this limit to success several lines of improvement have evolved. One of them is to quality assess the software quality assurance itself with the use of models like TMMi or Test Process Improvement. These might help to forge a smoother adherence to the standards, procedures and templates, but the emergence of better software seems to be more of a side effect then that is the result of these new models themselves.

A second response is to more stress that quality assurance of software is an independent activity performed in separate (QA) departments that kind of police software development. Although this helps to adhere to external regulations and audit rules it has little effect in the pursuit of building good software that solves the or is fit to be used for problem it is intended for.

These models, and others like them, have widened the gap between quality assurance through process and the act of testing software through skill. So much so that increasingly quality assurance and testing are considered as different activities that oppose each other. In my opinion we need both aspects of software development to do a good job. How we mix them however should depend on the context in which you apply them. But in whichever context the testing of software should have the purpose of delivering useful information about the product. To do this, in my opinion testing skills come first and then knowledge and use of standards or procedures follows to aid or enhance the act of delivering useful information.