Let’s discuss “done” as it relates to writing software versus testing it — code completed versus code validated. Here’s the scenario. A software developer has finished implementing a code module or, preferably, a story. This means he’s unit tested the code and it works as intended. Is he done?
Now, someone specializing in software testing runs manual and automated tests against the code. This effort is likely to uncover defects and inconsistencies. Not because the developer did a poor job but rather because software is complex. It’s easy to miss something or be unaware of a side-effect resulting from the new code.
This scenario often plays out as follows. The developer has moved on to another module or story. The tester files defect reports. Because the developer isn’t available to work on the issues, the defect reports become part of the backlog to be prioritized in a future iteration.
By the time the defects rise to the top of the priority queue, the original developer may not be available to work on them. Even if he is available, the passage of time may make it difficult for him to assess the defects and determine corrective actions.
This elongated code-test-fix cycle is the norm.
Does this seem efficient to you? Product manufacturing companies used to operate like this. Build stuff. Inspect it. Identify defects. Send defective products back for repairs. They’ve stopped doing that. Efficiency means identifying defects during the production cycle and taking immediate corrective action. Life’s never perfect and some issues will inevitably get through but they’ll be minimal.
Building great software requires a team of developers and testers committed to delivering finished — done — software. Every module or story has to be completely developed and tested by the team. There’s no such state as “almost done” or “implemented but not tested”. Such conditions offer a false sense of security and lead to more defects.
The team shouldn’t receive credit for a module or story until it’s fully tested and the defects have been resolved. If there isn’t enough time to fix the defects, the code is not done, the story is not finished, the affected item returns to the backlog.
Harsh? Maybe. You can always implement an exception process whereby the product owner must approve anything for distribution that’s not done. If the product owner is as tough on the team as I would be, it may be easier to just get the software right in the first place.
photo credit: Chrysler-Group via photopin cc