What is the goal of software testing?
It may surprise you
In a talk I gave last March (Do It In Production — Testing Where It Counts), I defined Testing as “A quantitatively expressed reduction of uncertainty about quality of a system under test based on one or more observations”. So does that mean the goal of software testing (and therefore the goal of the software tester) is to reduce uncertainty about quality of a system under test? No, that is merely a means to an end… a tool we use to get to the goal. The goal is
To produce software of sufficient quality so as to deliver value
I could have said “business value” instead of just “value”, but I have to concede there may be scenarios where the desired value is something else, can you think of any such cases?
And “sufficient quality”? Well there is a world of difference between the quality that is acceptable on Twitter and Facebook versus that say on SQL Server or a Point of Sale system. So yes, “sufficient” as defined by your what your product is.
So the astute may respond that the goal for Software Testing I just defined is the same goal as the Developers have, and the Program Managers have, and the Designers, and Business Analysts, and… well everyone who works on the product. Yup. Which is why is amazes me that disciplines can be set against each other, as in the classic Test/Dev tension. This is unacceptable. If test pushes back on Dev that they need more Dev Testing (e.g. unit tests), then the decision on whether to add more Dev tests or more features needs to be decided through the lens of the goal, and only that goal. If we are going to leverage production data to improve quality, then it stands to reason that monitoring and telemetry become a first class feature itself. It is no longer about a “trade-off” between features and testing, between features and telemetry. It is a team effort to deliver value.