Better Software - December 2008 - (Page 32)

Figure 2 took an hour. Each member of the team used a template similar to the one shown in table 1. As team members reviewed the current version of the Web site, they made notes under the various hats. The hats encouraged everyone—even the nontechnical team members—to voice their opinions rather than feeling excluded. At the end of the meeting, the notes were collated and analyzed. They covered various key aspects of the site, including: • Core functionality: how to update the content • Usability: page size, aesthetics, look and feel, etc. • Privacy and security: Who can access information? How well is the client data protected? etc. • Performance: only in general terms with no quantitative definitions • Process testing: including the interaction between people and the functionality offered by the Web site; who does what and when As a result of the feedback, the launch of the new site was delayed until various changes were made. The entire team also felt much more involved in the success of the project and were more committed 32 BETTER SOFTWARE DECEMBER 2008 to helping improve the new site. discussing release readiness Another area where the hats can help is for release decisions—should this software go live or not? Using the hats can help provide fresh insight into whether the software is likely to meet its release criteria. For example, I participated in a launch meeting for software due to ship in five days. I had nagging doubts about whether the software was ready but didn’t want to be perceived as the doom-ridden, dissenting voice on the project team. Just before the meeting, I spent about forty minutes sketching out what I knew about the state of the software using the template. In the blue box, I recorded my aims and objectives for this exercise and for the launch meeting. I collected facts in the white box such as the known bugs and release cycles. A couple of the bugs particularly worried me, so I noted my feelings in the red box; I’d be embarrassed if the software launched with them. Key project and product risks were added to the black box indicating concerns, problems, and risks. In the yellow box, I noted our goals and what we hoped the software would www.StickyMinds.com achieve once it had been launched. After filling out the remainder of the boxes, I started brainstorming ways we could increase our chances of launching quality software, soon, and listed them in the green box. When the meeting started, I was well prepared and able to explain my concerns and goals and even suggest ways we could help increase the likelihood of delivering working software. The ideas and suggestions were well received, and we decided to run a mini test-fest later that day, which found several high-severity bugs and identified a number of areas where usability could be significantly improved. As a team, we increased our velocity, improved our working relationships, and produced better software—all by using the six thinking hats. Discovering Testing Hats In his presentation, “Schools of Software Testing” [2], Bret Pettichord describes a number of different approaches to software testing: • The analytic school—sees testing as rigorous and technical with many proponents in academia • The factory school—sees testing as a way to measure progress with http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - December 2008

Better Software - December 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles What's a Manager to Do? Six Thinking Hats for Testers The Key to Good Interviewing 2008 Salary Survey Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.