Design for test - a fundamental tenet in the development of quality software. [“Quality software” satisfies its requirements and ONLY its requirements, and runs in acceptable time and space.] Given this basic tenet one would imagine the Developer works closely with his test counterpart, collectively specifying and designing efficient tests to assure an artifact’s quality. Of course, one would also expect the converse, the Tester and his development counterpart working in concert to define which test result data is most useful to quality improvement and process evolution.
Sadly this far from the case and I didn’t give it much thought until I attempted to “strengthen” the developer-tester cohesion in my own company.
We talk about how improved PCN security is impeded by cultural differences b/w operations and IT folks, well, funny enough, the same can be said about software quality; its improvement is impeded by cultural differences between testers and developers.
Consider the following:
- Developers write code for requirements that are satisfiable and in the case when they’re not, the requirements are “adjusted” accordingly.
- Testers write code for requirements which, by their very definition (to prove the quality of an artifact), are not satisfiable and are excited by such.
- Developers expect their questions have answers, testers accept theirs do not.
- Developers, in general, work, live, and play in the complexity space of P - problems solvable in polynomial time and space.
- Testers on the other hand, live, work and play in NP – problems only solvable in exponential time and space (effectively computationally intractable, i.e. problems for which there are no feasible solutions). Approximations, probability based randomized algorithms, best guess algorithms, are common place.
These may seem like minor differences, P, NP, etc. But they are a fundamental indication of an overall mindset that, generally, mixes like water and oil: the best you can expect is a weak emulsification.
The Developers and Testers who embody their profession (yes, the dedicated zealots such as I) are diametrically opposed ergo they yearn to work further apart, ergo neither job is performed optimally, hence design for test is handled extremely poorly in practice. And that’s reason #4,125 commercial software is exploitable.