“Done” causes me no end of trouble. I’ve been struggling with this for years, with questions that seem to make little sense, questions that may be familiar to you: “when will testing be done?”, “is testing done yet?”
I recently attended a presentation in which it was asserted that “testing is the culprit of many schedule delays and cost overruns” (and here are the best practices that you must apply in order to keep testing in check). This is another manifestation of the “done” problem, and is utterly dysfunctional. I’ve worked on a number of projects that took this view, projects where done was the only measure of success and testing had to be done by a given date or else was considered a failure. Of course testers were not alone in this: developers had similar dates to meet but somehow never seemed to have any problem, well, as long as you don’t count the huge swathes of missing functionality and the bugs that Mr. Magoo would have had a hard time missing. Somehow, this always seemed to reflect badly on testing’s ability to be done. One of Jerry Weinberg’s many wonderful phases (and one that permeates the Quality Software Management series) is beautifully applicable: “it’s not a crisis; it’s the end of an illusion.”
For some time, I tried to counter this with the argument that testing would never be done (in the sense of having tested everything) but had mixed results. Latterly, I’ve come to the conclusion that the done problem turns on a fundamental misunderstanding as to the nature of testing. For a project manager, who sees the world through a lens of Gantt charts and tasks to be completed, it makes complete sense to be concerned with when testing will be done. Unfortunately testing is not like that. Unlike developers we are not creating something tangible: in this way the nature of our work is far more akin to that of the project manager, and asking when testing will be done makes about as much sense as asking the PM when their management of the project will be done. Testing simply isn’t a set of tasks that need to be completed before the end of the project. It provides information that helps others to make decisions. Period.
When asked when our testing will be done, perhaps we should answer with a question of our own: when would you like us to stop investigating quality? The stopping heuristics suggested by Michael Bolton (et al.) provide a great starting point for the conversation that would inevitably follow.