May 7th, 2015 by Adam Sandman
agile test management requirements management
When making the transition from document-oriented information storage to record-oriented information management tools, there are a number of problems which can make the process difficult, or even unsuccessful.
In part 1 we addressed:
- Overlooking context and background, and
- Being hung-up on report formats.
Here we shall address two more traps into which people easily fall when adopting new specialist tools for managing data such as requirements and tests.
Imposing excessive Configuration Management on record based data.
When using a word processor to manage important test or requirements information, there is good reason to subject such documents to a universal CM process. Access control as well as version history are often the purview of corporate tools and their associated managers. But there is a tendency for these corporate CM authorities to become too possessive of the CM process and insist that all external CM protocols be applied to record based tools even when they offer their own in-built CM capabilities.
It is important to remember that their objectives are for the common good, otherwise trying to reconcile these internal and external CM processes can result not only in procedural conflict but in inter-personal conflict as well.
To avoid the clash:
- Include configuration managers when planning the process of bringing a new tool on-board,
- Ensure that any CM capabilities offered by the new tool are well understood and appreciated by all,
- Find ways to integrate in-built CM with corporate CM requirements without significantly undermining either, and
- Be prepared for some give and take in order to be successful; remember that the alternative is far worse.
Figure 1: Native change history shown in Inflectra’s SpiraTeam
Using an old process for a new tool.
Over time, processes and procedures may have evolved to support the use of a word processor to manage project data such as requirements and test cases. For example, it may be necessary to frequently publish current documents to a shared site for easy access or to use complex test case numbering schemes. When moving to a record based solution, revisit the processes and procedures in place.
Not only might it be possible to significantly simplify them, they may need to be changed to allow proper use of the new tool.
Looking at the problems described here and in part 1, it is easy to see that when moving from a document-based tool to a record based tool for project data there are serious pitfalls to avoid; it is not simply a matter of replacing one with the other. Plug-and-play might work when replacing one word processor with another, but the evolution of an organization leads to the need for specialist tools and the introduction of specialist tools requires some fresh thinking to achieve success.
In the third and final part of this series we shall see how migration to a test management or requirements management tool can be made easier by the tools themselves.
You may also be interested in:
Requirements Sign-Off
Documenting Requirements in Agile Projects
When Good Workflows Go Bad
How to Choose a Test Management Tool