Doing Inventory

Exposing rogue features and reducing bloat

important role when you have fairly open requirements. When a requirement allows many items to be added to a product, normal testing of the requirement may only result in one of these items being tested. This step is where you formalize the inclusion of all of these items into the testing process.

A common area in this regard is that of examples, or samples. Typically, the requirements don't specify every example that will be shipped with the program, and the examples end up being a collection of those created for testing requirements, debugging the application, or showing off the GUI. Here it is important that you really want to make sure all the examples demonstrate correctly what they are supposed to, and that each example meets the quality standards of your product.

It is clear that the first few iterations of this process will likely be the most difficult; it is a daunting task to go from tracking zero assets to the thousands, or even tens of thousands of assets in a reasonably sized project. Don't be aggressive in your first attempts; instead, concentrate on tailoring the technique to your needs and creating the tools you will need to track this work. With each iteration, you can improve your tools and the level of detail you track. It should be clear that a simple editor with one EXE, a few DLLs, and some examples is not going to require the same effort or tools as a modern real-time strategy game with some 40,000 image files. In the latter case, you are advised to try to integrate this technique into your standard asset management process (late reconciliation may be too costly for your project).

The simplest form of this process does not require any other changes in development or testing. You can implement this over several weeks, or months, and not worry that it might interfere with your existing process. Once you've started, the confidence you have in your product should improve. You can feel more secure that there aren't any hidden aspects of the program left untested, or that some spurious library isn't going to cause the program to crash. Ultimately, this gives one more little boost to product quality.

(Note: This process does not replace asset management, rather it is best seen as the quality control process for asset management. Use as much information as possible from your asset management system–it may reduce the workload of this activity.)

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.