English | EN 
Software testing is already out there for more than 25 years, but in essence it is still the same profession as in the beginning despite all technological evolutions over the last decade such as cloud, mobility, social media, test automation and many more. What we all know: software testing can be described as an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Providing valuable information about the product quality towards the stakeholders was and is still the main goal.
Assuming that you know what this valuable information should be and looks like, the most interesting question is, of course, how do we get to this? This is the moment on which many organizations and (test) consultancy companies come up with their test process or methodology describing in detail or in high level terms how they envision testing, how it is organized, what activities are performed during the various testing stages, what are the ins and outs, etc. Multiple books, wikis or papers have been written to explain how to organize testing.
All these different processes or models have one thing in common, although it is not so very visible among all process flows, activities, phasing models and other nice artifacts which are the building blocks of this test model: the intellectual analysis and creativity of the tester. This is really the core of all testing activities which is directly related to finding the present bugs and verifying the possible situations in an application. The accuracy and analytical skills of a tester are still the crucial starting points for a successful test. And of course this magic creativity needs to be well facilitated by enough structure, time and other means.
But something is not right about this. Testers should not get all the responsibility for performing the needed testing to achieve a certain level of application quality. Testing is namely not adding or removing quality, it just reports on quality. Providing valuable information, remember? So quality doesn’t come from testing, but from an improvement of the total development. In this context, it is a pity that a lot of testing publications only focus on testing as a kind of separate activity in IT. This silo-based thinking should be replaced by a more holistic view on quality in IT projects. Instead of keeping testing as something separate, we should embed quality activities in all activities or phases throughout the IT lifecycle. And yes indeed, a part of this quality measures we could still call testing. So a full IT project should allow that quality activities are incorporated in the regular processes.
That’s a completely different mindset to look at “testing” as we know it before. The testing activity is still the same in its core as it was in the beginning, but its position is changed, that’s a fact. In other words: maybe we should burry the term “testing” and start talking about quality in general. After all, customers and users don’t care about testing as such, but only the quality of the product, right?
