Bob Marshall, in a bunch of his recent tweets on #NoTesting, quoted Philip Crosby, the author of Quality is Free. Here's a couple:
Why spend all this time finding and fixing and fighting when you could prevent the incident in the first place?
If managers think testing is the answer to quality, then people will test.One of Crosby's arguments, as I understand it, runs like this: The quality of a thing is the extent to which it conforms to its requirements. The cost of making something, finding it doesn't conform and then fixing or remaking it is higher than the cost of making it to conform in the first place. So you can have a quality thing for (at worst) no additional cost.
Which can work, as long as you're prepared to consider anything outside conformance to requirements to also be outside of any quality considerations.
In the same #NoTesting Twitter stream Marshall said:
The problem of testing being seen as the only path to software quality is a very real, longstanding problem.
People demand testing when they have little or no faith/trust in the dev team. So, test evermore? Or work on the trust issues?One of Marshall's arguments, as I understand it, runs like this (see e.g. the comments in More NoTesting): The traditional "develop" and "test" roles by their nature cause a separation in the creation and inspection of an implementation. This lengthens any feedback loop. Removing the test role and pushing the inspection back into development tightens it and this is considered desirable. No test role means no testing, or #NoTesting. (He declines to define testing in No Testing.)
Which can work, as long as you're prepared to consider anything outside verification of implementation to be outside the remit of testing.
Crosby's work was aimed at manufacturing rather than software development while Bob Marshall's work is steeped in software development. Regardless, in both cases, the generalisations stemming from restricted contexts can be provocative to us in our software development world.
And to my mind there's no problem with that, because being prompted to reconsider a position can be useful - see e.g. "Test automation is any use of tools to support testing". We often do things the way we do them simply because that's the way that we've been doing them.
But that doesn't mean that all the things we might (with a broader view) be prepared to think of as quality or testing considerations can be had for nothing or are not useful. In order to meet the needs of those concerned in any software development process we do best to understand them, the motivations for them and so on - see e.g. Weinberg.
To get to the desired (bigger picture) quality involves asking the (bigger picture) questions; that is, testing the customer's assumptions, testing the scope of the intended solution - you can think of many others - and indeed testing the need for any (small picture) testing, on this project, at this time.
Whether this is done by someone designated as a tester or not, it is done by a human and, as Rands said this week, I believe these are humans you want in the building. #GoTesting