Test plans are seldom followed as written, project plans hardly ever fit the actual progress, and process models are rarely followed to the letter. Markus Gaertner examines why most of our documents become obsolete and gives advice about whether or not to continue to write and maintain them.
The Swedish Army has the following dictum [1]:
When the map and the territory don't agree, always believe the territory.
This dictum applies to software development in a number of ways.
Requirements
When the requirements document and the requirements don't agree, always believe the requirements.
On projects, the most fragile document is the requirements document. This occurs for several reasons. First, your customers may not completely know what they want. This is normal, since they are trying to create a mental picture of their future. While the customers might have a mental picture of what they need, transmitting it to others can be problematic. Mental models are translated into written and verbal language, transmitted over noisy communication channels where relevant information may be lost, interpreted by the receiving side of those channels, and, finally, incorporated into some software. And then you wonder why you did not meet your customer’s requirements.
The second problem with requirements is that they change over time. For competitive advantage, customers must be able to react to their particular business and markets. If they can't react, they will go out of business. Therefore, if you cannot adapt to the changing requirements of your customer, you, too, may go out of business. Since it’s nearly impossible to think about all the changes that may come up during projects, you should leave the code and the tests as flexible as possible.
Third, requirements change not only for the sake of your customers’ competitive advantage but, over time, the perception of “high quality” software may change. A new operating system may launch with a new user interface look and feel, and your customer may want to adopt it. Human interaction models change and while some of these changes may be predictable, many others are not. Some changes may creep in slowly; others, like changes in regulations and law, may occur month to month.
If the document that holds an interpreted snapshot of therequirements at some point in time is not able to cope with these changes as they occur, we had better believe the requirements rather than the document.
Test Ideas
When the test plan and the tests don't agree, always believe the tests.
There can be a big difference between the test plan document and the ongoing activities on a software test project. The test plan document is an output of the planning activities surrounding testing. Therefore, it lists some testing activities that were thought to be necessary at some previous point in time. This might be early in the project, when little knowledge about the product to be built existed. Therefore, when we run into a situation where the test plan lists an activity different from what the testers should be doing right now, reflect on whether the test plan defined a different activity based on lack of feedback on the actual progress, experience gained, or whether the tester is going off on a personal tangent.
If the document was written with some particular situation in mind and that situation unfolds in a different manner, testers need the right to change their course of action. When testing is not adapting to the context in which it is executed, we may miss critical bugs and information about the software that should be shared with our stakeholders.
Projects
When the project plan and the progress don't agree, always believe the progress.
In chapter ten of Quality Software Management: Congruent Action [2], Jerry Weinberg describes the Addiction Cycle. When the actual progress made falls behind the planned progress, a project manager is put under pressure to catch up. Giving in
| Attachment | Size |
|---|---|
 XDD16074filelistfilename1.pdf | 237.69 KB |
About the author
Markus Gärtner studied computer sciences until 2005. He published his diploma thesis on hand-gesture detection in 2007 as a book. In 2010, he joined it-agile GmbH (Hamburg, Germany) after having been a testing group leader for three years at Orga Systems GmbH. Markus is the co-founder of the European chapter in Weekend Testing, a black-belt instructor in the Miagi-Do school of Software Testing, and contributes to the ATDD-Patterns writing community as well as the Software Craftsmanship movement. Markus regularly presents at agile and testing conferences, as well as dedicating himself to writing about testing, foremost in an agile context.
