Typically, testers write a test case for the one component and sub-system they are testing, thus limiting its value. What if you could repurpose and reuse previously developed test assets across several components and sub-systems? Vishal Chowdhary shares three test patterns he has encountered many times while testing various .NET Framework components at Microsoft. The “Test One, Get One Free” pattern describes how to test features that are layered-where a feature enhances an inner core feature. The “Features Get Tested Alike” pattern describes how to test similar features that are exposed via different interfaces to the user (e.g., through an API vs. the user interface). The “Standing on the Shoulders of Giants” pattern lays down design guidelines to optimally build reusable components that can be leveraged between feature teams testing large software products.

Don't let anyone tell you otherwise-doing testing well on agile teams is hard work! First, you have to get management over the misconception that you don't need specialist testers within agile teams. Next, you have to integrate testers with the developers and provide holistic, high quality results. Those are just the easy challenges you face. Then, comes the hard part! Bob Galen explores more difficult agile testing contexts-how to attack a total lack of test automation, how to remain agile in highly regulated environments, how to serve your PMO or Testing COE while remaining agile, how to organize testing when your agile team is globally dispersed, how to blend traditional testing processes with their agile counterparts, and more. If you're in a difficult testing context within an agile development environment, come and join the conversation. You'll find examples and options, but no silver bullets. Remember-it's HARD!

Although much information is available on test design techniques, very little is written on how to select which techniques to use for the job at hand. Derk-Jan de Grood believes that many testers find it difficult to select the right techniques and very often use a technique simply because they know it. Instead, the best reason is that the technique is likely to discover the most important errors quickly. Derk-Jan shares his insights on test technique selection and poses three questions you should ask yourself when selecting a technique: What types of errors do I want to find? What impact do these errors have in production? Is the needed information to perform these tests available? He then lays out a list of common test techniques and discusses which error types they are most likely to discover. Take back a new understanding of test technique choice and selection to become a better software defect sleuth.

It seems that developers have as many definitions of “done” as Eskimos have words for “snow.” But without a clear definition of done, it is difficult to gauge progress on a project. Menlo Innovations has a simple solution. Instead of declaring a story card or feature done on its own, developers collaborate with the business analyst and testing teammates to determine when the application meets their requirements. Tracy Beeson highlights the power of asking one deceptively simple question that has multiple, complex answers that can, if not implemented with care, upset the status quo and lead to new problems. Using loosely orchestrated role playing, you'll practice this approach for discovering when done is really done.