Ever since I started software testing I was surprised by the different names the test functions have ranging from say “Software Development Engineer in Test” to just “Tester”. At the time I did not pay much attention to this as testing to me seemed to be similar regardless of the title you have while doing it. Some time later however, after  listening to Stephen R. Covey’s 7 habits, I was reminded of these different titles. Covey mentions, in the Paradigm chapter, the shifts in paradigm that can come with a change in the title you carry. At that time my idea that all software testers basically performed the same activity had also changed and the subject of the title by which you test intermittently came back to my mind. And now some years later I have found both time and inspiration to use it as subject for a number of posts. In this small series of posts I will, start to, shape a model  of my perception that the title by which you perform your testing activities has consequences on how you and others perceive and approach your work in software testing.

This first post in the model relates to the origin of the computer itself.

The first computers were mostly a product of scientists, civil engineers (like Leibniz, Babbage, Atanasoff or Zuse), and others building more or less programmable hardware attempting to both solve and speed up the solution of calculations. The application specific machines that emerged out of this eventually not only calculated based on their physical configuration but also based on data and settings fed into them.

The design, implementation and modification of this data known as software eventually was, and still is, seen as an engineering activity known as Software Engineering. (The origin of the term is linked to a NATO report  in 1968)

This part of the model then represents the engineering paradigm.

In the engineering paradigm testing is seen as a specialisation or a sub-discipline of software engineering. In this paradigm software test engineers see themselves closely related to software engineering and by doing so favorably like to share the perception that they perform based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering. Like their counterparts their focus lies first and foremost on the functional correctness of the software engineering product, the code. The code itself and it’s syntax or grammar (patterns, coding practices, etc.) is however mostly left to the developers or programmers.

The software test engineers responsibility is to check whether or not the software:

• Works; does the software or section of software work once installed
• Contains all functionality; checking that all functionality that is described in the specifications is present
• Is functionally correct; does the function do what is described in the specification of that function

For a lot of people then, whether or not involved in software development or even if involved in software testing themselves, the following thus describes what testing is about:

Verify that it works and is built as specified.

Obviously software testing has evolved since the early days of building computers using switches, relays and vacuum tubes. The consistent use of the engineer part in titles for software testing however signifies, in my opinion,  the implicit focus on the correctness and completeness of the software built rather than more user or quality attribute orientated views.