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.

What’s in a name – Part 1, I am an engineer

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.

The hungry eye

This blog post is a personal reflection on the first annual DEWT peer conference that was held on June 11, 2011 (#DEWT1). The conference was opened with a (keynote worthy) presentation by Zeger van Hese on “Artful Testing”. Although quite a few items of his presentation struck a chord with me this post will only go deeper into one of them; “The hungry eye”. The story of the hungry eye shows how a change in perspective and representation can bring new insights and meaning to subjects that otherwise would be ignored.

The hungry eye – Walker Evans

In 1936 Fortune Magazine sent a poet, James Agee, and a photographer,  Walker Evans, to Hale County in Alabama to document the life of sharecroppers during the Depression. Once finished the magazine saw no reason to publish their lengthy and controversial work. James Agee refused to revise the initial draft and eventually they published it themselves as “Let Us Now Praise Famous Men?”. Although the book did not have a great start in his time during the fifties and sixties the poetic photo book was to become one of the most influential works to portray the brutal side of life in America.

One of its then critics describes it as follows “On an existential level, Agee’s text is a deeply felt examination of what it means to suffer, to struggle to live in spite of suffering. On a personal level, it is the painful, beautifully written portrait of one man’s obsession. In its collaboration with Evans’s photographs, the book is also a groundbreaking experiment in form.”

Walker Evans pursued his style of photography and was able to bring new meaning and perspective to otherwise ordinary objects. He was the first to have an exhibition devoted to the work of a single photographer in the Museum of Modern Art and eventually his style of photography became known as the “Hungry eye”.

To me this  “Hungry Eye” style or genre  represents a ground breaking shift by Evans in how  the field of photography looked at the world and how to represented this in a message to the viewers.

Such a shift in genre is what links this to software testing for me.

Software testing has used and is, like art, using different genres, such as the V-model, Waterfall , TMap or Agile to shape and structure its view on the world. All of these genres bring with them a modeled perspective of software development. The knowledge of these genres and the ability to identify them, to look critically at them or use them thoughtfully is one of the skills a good software tester should have in his toolkit.  Of course eventually you may, and perhaps should, develop a preference of genre, but you should never lose sight of the possibility to change your perspective and use elements of a different genre that might bring you further.