Since Martin Fowler completed his now-classic work Refactoring: Improving the Design of Existing Code, few programming practices have been more effective-and more controversial-than refactoring. Refactoring is effective when you study and practice it diligently. It remains controversial because many development managers think developers should be adding features, not reworking old code. J.B. Rainsberger takes you deep inside the process of refactoring, including: how to refactor code you don't know well, when to refactor toward a design pattern, and the four key elements of simple design that should guide your refactoring. He explains the hazards of refactoring, when not to refactor, and how to refactor in such a way as not to upset your boss. After this class, you will be able to refactor your own code more confidently and effectively. You might just impress some of your colleagues along the way.

Classification trees are a structured, visual approach to identify and categorize equivalence partitions for test objects to document test requirements so that anyone can understand them and quickly build test cases. Join Julie Gardiner to look at the fundamentals of classification trees and how they can be applied in both traditional test and development environments. Using examples, Julie
shows you how to use the classification tree technique, how it complements other testing techniques, and its value at every stage of testing. She demonstrates a classification tree editor that is one of the free, commercial tools now available to aid in building, maintaining, and displaying classification trees.

• Develop classification trees for test objects
• Understand the benefits and rewards of using classification trees
• Know when and when not to use classification trees

Want to improve the quality of your products? Of course you do. But how? Mette Bruhn-Pedersen uses a simple, but effective method that includes both clients and users in the development process. His company organizes and conducts verification sessions early in the development process. These sessions consist of two parts: First is a demonstration of the implemented functionality using test cases as examples; second is a "play" session in which the customer is given control of the system to explore the functionality from a business perspective. By observing the client, testers get a better understanding of what functionality is most important to the client as well as increasing their knowledge of the software's intended use. Sometimes, the clients find important, new defects during the session. And almost always, testers learn they need to add new test scenarios based on their observations during the play session.

If your background is testing on traditional projects, you are used to receiving something called "requirements" to develop test cases-and sometime later receiving an operational system to test. In an agile project, you are expected to test continually changing code based on requirements that are being uncovered in almost real time. Many perils and pitfalls await testers new to agile development. For example, a tester new to agile might think, "I'll test the latest 'stories' on Tuesday when I get my next build.” And you would be WRONG! Waiting for a new build will almost always put you an iteration behind the developers and in a schedule hole from which you cannot recover. To avoid this trap, you must start testing as soon as the developer has completed a feature story, even before coding begins.