Reasons for Using an Inventory

Testing without a test inventory is like going to the grocery store without a list. The shopper will probably proceed by walking down each aisle and examining each item on the shelves in order to make a determination. Do I need this or not? Can I afford it? Will it fit in the basket? This continues until the shopper runs out of time, money, or energy. At that point, the shopper hurries through the rest of the store to the checkout, perhaps collecting a couple more items on the way. Let's assume that the shopper can afford to pay the bill. It's likely that when the shopper arrives at home, he will discover that he did not get certain items that he really needed, like milk or bread, which means he will have to make an unscheduled return trip to the store or do without. There is also a good chance that he made some impulse purchases, like toffee pecan ice cream, and some duplicate purchases, like another jar of green olives when he already has three in the cupboard.

An effective and efficient trip to the grocery store begins with a good list and a budget. Ideally, the shopper arrives at the store in plenty of time to get the job done. The efficient shopper will proceed on some systematic path through the store, usually aisle by aisle, finding the items on the list, checking the price, and reviewing the other offerings as well. This is how we find things we needed that were not on our list, and this is how we discover new items. "On my way down the exotic foods aisle, I saw this new fajita marinade and thought it sounded good. Let's give it a try."

If time is short, the efficient shopper will try to plot a path that will minimize the time required to acquire the items on the list and ensure that he does not have to double back to get any items on the list.

Because of the way software development works, software testers do not usually get in the store until just before it is going to close. All the experts agree that using a list is the most efficient way to do the shopping, but only 1 tester in 30 reports that he prepares a list of the tests that he thinks could be performed, or all the tests that should be performed.

Using a list helps minimize the mistakes that we can make because something was forgotten, and it reduces the waste of unnecessary purchases. How good the list is depends on how carefully the cupboards were reviewed during its preparation. The most comprehensive and therefore the best list is the public list posted on the refrigerator, where everyone can add to it.

As good as all these reasons are for using an inventory, they are not the main reason that I use test inventories.

Note 

The main reason that I use test inventories is that they protect me, the tester.

If I tested everything on the list and the project failed, I have still performed my part of the agreement. This is part of project management, engineering practice, and contract law. I can show clearly what I plan to do and not do, what I have and have not done. If management or any other party sees something amiss, they are required to say so, or they will carry a share of the blame later. If the scheduled time has to be shortened, I can ensure that whatever time is available is spent testing the most critical items. But I am not responsible for completing an effort if agreed upon time or resources were not available.

I make management aware of every test that they are choosing to forego if they choose to downsize the test effort, or if they choose to forego the systematic approach and go with a purely ad hoc effort. Have you ever heard management say something like, "Of course you can finish it. I will give you 10 folks from editorial. They can test it in no time." (It indeed.) On the surface, this may seem like a good idea, but it is one of the poorest solutions available. There probably is not any time budgeted to train these newly designated testers on how to test or how to follow a test plan. The odds are that the test effort will quickly degenerate into an ad hoc free-for-all. The good folks from editorial will not be sure how to reproduce most of the bugs that they find. Development will probably return their bug reports as "unreproducible," and the real testers will lose a lot of time chasing chimera when they could have been performing meaningful testing.

Note 

I do not write test plans anymore; I write a contract to test.

I started writing contracts to test long before I started testing as a consultant. It is too easy for a test plan to be ignored and forgotten. In a commercial software shop, the testers are usually the first ones shot when the product fails. It is not so easy to shoot testers who are holding an agreement that management signed and then chose to ignore when deadlines approached.