English | EN 
Today IT delivery teams are convinced that quality is a very important focus. Over the last decades, quality engineering has evolved out of the narrower activity of testing. This evolution is reflected in the changing definitions of testing over the years. In this blog, you will make the journey along with these definitions and see my brief analysis of this evolution.
The first definition of testing that I know of is in the book “The art of software testing” by Glenford Myers which was published in 1979.
He defines: “Testing is the process of executing a program with the intent of finding errors.”
The idea back then was: find the errors, solve the problems and you will have perfect software. But in the 1980’s software quickly grew so complex that it became clear this approach was not feasible.
The first book in the TMAP series, “Testing according to TMap” (1995) aimed at making testing a structured process and introduced this definition: “Testing is a process of planning, preparation and measuring, aimed at establishing the characteristics of an information system and demonstrating the difference between the actual and the required status.”
The idea was: an information system is never exactly what was required, we will investigate it and tell where it doesn’t match, so someone can fix it.
With this definition the focus still is that IT systems have problems that need to be fixed.
In the middle of the “zeroes” two new definitions of testing were published, one in the TMap NEXT book and the other in the ISTQB glossary.
The book “TMap NEXT” defines in 2006: “Testing is a process that provides insight into, and advice on, quality and the related risks.”
Very short and straightforward and with a specific reference to quality and the quality risks. This is the information you need, to decide if you want to start using the product. By the way, in this definition apparently the product can be anything, it is not limited to IT products.
The focus now is on measuring quality to provide valuable information.
In 2007 ISTQB published the following definition that still is unchanged to date:
“Testing is the process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects.”
In this very lengthy definition, the starting point is that the test object is good, (“demonstrate they are fit for purpose”), but at the end this definition still states testing looks for faults (just like Glenford Myers already put in his definition).
Unfortunately, ISTQB has no direct reference to quality. But they do refer to both verification (satisfy specified requirements) and validation (fit for purpose).
On 17 March 2020 we launched the latest book in the TMAP body of knowledge, titled “Quality for DevOps teams”. In this book the definition of testing is:
“Testing consists of verification, validation and exploration activities that provide information about the quality and the related risks, to establish the level of confidence that a test object will be able to deliver the pursued business value.”
This definition has many elements from previous definitions, it is a result of an evolution. New is the extension with exploration (mainly to explore unexpected behavior and unforeseen possibilities). Also new is the emphasis on providing information to stakeholders so they can establish their confidence in business value, because we are taking the pursued business value as the starting point for testing.
This definition also aims to convey the notion that sometimes mediocre quality at the right moment is better in generating business value than having the highest quality too late.
Over the years we have seen that testing (and in a broader sense quality engineering) made the journey from “find faults and fix them” to “determine whether it is good enough to generate business value”.
Good luck and have fun testing!!
