How Valuable Is Software Testing? Do We Even Need It?

How Valuable Is Software Testing? Quality Assurance (QA) has been around for a long time, and QA techniques are many and various. Yet software products continue to be released on to the market before the bugs have been fixed.

In some cases end users are expected to find and flag issues to the product owner. In other words, they are being taken for granted as a convenient and cheap form of quality control. But not all end users are able to take any action, and suffer in silence, not knowing what, if anything, they can do about it.

In the software development space where we operate, we might take the view that testers are really only needed when developments turn out badly. “Improve the development, problem solved,” some say. But is it really that simple? Perhaps it’s time to go back to first principles.

“The absolute fundamental aim is to make money out of satisfying customers.” – John Egan

The main objective for any software product is not what the supplier or development team believes it can or should do, but whether it is fit for purpose, easy to use, does what it claims and, of course, returns a profit. The final arbiter of this is the end user. As the industrialist John Egan once remarked, “The absolute fundamental aim is to make money out of satisfying customers.” For your users, perception is everything, and their reaction might not always accord with the product originators’ expectations.

We might well ask ourselves why software ends up in this imperfect state in the first place. A look at the workings of a software house will show us that:

  • Under time pressure software developers will attempt to get a feature completed and then move on to the next
  • They are less likely to spot faults in their own work and might be tempted to bend the Acceptance Criteria (ACs) to get the work passed
  • A developer, with in-depth knowledge of the platform, will tend to focus only on Acceptance Criteria or a particular feature
  • By contrast, a tester will be looking at the product from the user’s perspective.

There are therefore two distinct roles implied here, each with a different emphasis.

Separation of the two will avoid the in-built conflict of interest that arises when the developer and tester are one and the same person and where there is a real temptation to cut corners in either role, or both. What is sacrificed in the process is the key benefit of ‘objectivity’.

Developers will ask “Does it work?”, whereas testers will ask “When will it not work?”

It is human nature to only reluctantly admit our faults, especially when appraising our own work; more reluctantly still when under pressure. Under such conditions, a developer’s interpretation of AC is likely to differ from that of a tester. Developers and testers also ask different questions. Developers will ask “Does it work?”, whereas testers will ask “When will it not work?” This is why it is always advisable to use a tester for checking.

The conclusion from this is that the involvement of a test team in checking will lessen the stress of development activity and spread the load of responsibility. Common sense also suggests it would be beneficial to have the involvement of a third party (irrespective of whether they are a developer or tester) in the interests of objectivity.

Creating something and checking whether it works are two clearly distinct roles that need separation. What is clearly not acceptable is to leave it to end users to find where the mistakes are.

Original article extracted from