Chapter 8: Tools to Automate the Test Inventory

Overview

When I worked at Prodigy, each of my projects got its own 3-inch, blue, three-ring binder. The binder contained all the information required to understand, validate, and verify the project. Topics were separated by sheets with plastic topic tabs and annotated sticky notes of every color that stuck out from between pages at odd angles. The blue book was typically full to overflowing. The papers in it were a colorful hodgepodge of photocopies, faxes, and hand-drawn pictures. The formal ones were on quadrille grid paper, but many were on notepad paper and the odd napkin. The colorful part was not only due to the stickies but because most pages were liberally retouched in yellow, pink, and green highlighter.

The inventory figured prominently in the binder, as did the bug statistics and the list of open issues (closed issues were removed to a binder of their own to conserve space), delivery schedules, project dependencies, and lots of other test essentials. I took a lot of ribbing because I showed up at every meeting with one of those stuffed binders. But when anyone-manager, developer, tester, operations support, or even business partner-wanted to know something about the application or the system it was running in, he or she came to ask me to consult the blue book.

Today, my blue books live in my Web servers, under the regular scrutiny of my search engine. Now when someone wants to know something about the project, I direct him or her to the appropriate search page. Even though I can now keep more information than in the binder days, the type of information that I keep in Web sites hasn't changed much over the years, but I create it and maintain it a lot faster and with a lot less work. Where there were once sticky notes, today there are hyperlink menus. The colorful highlighter marks have been replaced by the search engine's transient gray highlight covering your search keywords in a document "hit." All in all, it's bigger, better, faster, and a lot smarter than the blue books, but when I go out consulting, most of the testers I meet are still trudging around with stacks of paper and no Web site to call their own.

Except for the time testers spend testing, most of their time is devoted to managing and preparing test documentation. Automation techniques for test documentation are both an excellent quality improvement opportunity and a potent tool for shortening the time required for documentation, and therefore, the test effort. My studies from 1993 to 1997 showed that document automation can reduce the time required to write the test plan, test scripts, and reports by as much as two-thirds.

My work with high-function Web sites from 1997 to 2003 has shown that Web-based automation can be used to automate the creation of many additional types of documents, such as test scripts, checklists, and status reports, as they are needed. This documentation is always up-to-date, and all parties are assured that they are getting the same document all the time, no matter where they are in the world. Perhaps even more importantly, the built-in search engine in the Web server allows the testers to find the information they are looking for in all those documents quickly.

The savings from this type of automation can be profound, and it can also serve to facilitate culture change in an organization. I have noticed that the speed with which testers deliver an answer to management has a direct relationship with their credibility. Of course, the correctness of the answer is also a factor, but I will leave that for a different discussion.

In this chapter, we discuss both types of automation in this feature. We also talk about the tools and the process that I use to evolve the test inventory. Again, I use different tools and different processes based on the needs of the project. The steps described are offered as guidelines and seed ideas only; they do not need to be followed precisely. Feel free to be innovative in the sources you use to begin your test inventory. Each of the tools discussed in this chapter has its strengths and weaknesses.

General rule of thumb: 

Use the sharpest tool in the shop for the job at hand.

Recently, a fellow tester asked me to evaluate a dedicated test tracking tool. The tool provided special document templates for most required test documentation, as well as customizable forms to be used to create and track tests. Finally, all documents could be stored in a specialized Web site. His group wanted to improve their efficiency, and they were willing to spend their own time to learn to use this tool set. The license for the 10-person test group would cost about $15,000.

I evaluated the tool and had my CS staff, who are my in-house testers, look at it as well. All of us had the same reaction: "Why spend money on a tool that just does what we already do with our Microsoft Office tools?"

Instead of telling the tester's group this, I asked what their goals were for the new tool, how quickly they thought they could convert to it, and what they thought the payback time would be for it. Then I asked them to consider what it would cost them to invest in their knowledge of Microsoft Office, which they already had installed, to learn how to create their own forms and document templates, store them in their own database, and use a SharePoint Team Services site for their specialized test Web site.

The answer surprised them. It turned out to be far more efficient for them to spend money on themselves to become educated on how to better use the tools they already had on their PCs. There were several additional benefits to the test department, as well as the improved efficiency of the next test effort. Chief among these was the prestige that came with deploying and capitalizing on one of the most useful and technically advanced Web sites in their company.

Sometimes the answer is simply to invest in learning how to use what you have better-learning to use more of its capability more efficiently. It makes you more valuable, too.

Note 

Invest in yourself; learn to use the tools you have well.

Now let's look at this process using tools from the Microsoft Office Suite. For better or for worse, the Microsoft products are ubiquitous, and even high school kids today have training in the use of Word, Excel, and often PowerPoint. With the advent of the Web, there are more and more international projects being undertaken, and Office is there too, with internationalized dictionaries and even some modest translation capabilities. I apologize to those of you who use a different office product, word processor, spreadsheet, and so on. However, even though the specifics may vary, these instructions should give you the general direction in which to go.



Software Testing Fundamentals
Software Testing Fundamentals: Methods and Metrics
ISBN: 047143020X
EAN: 2147483647
Year: 2005
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net