|
Testing Microsoft Office: Experiences you Can Leverage to Drive Quality Upstream Have you experienced those weeks when the new features being added to builds just flat out don't work? Do you strive to have a testable build throughout the full product development cycle? Are you tired of the mountain of bugs crushing you just before time to ship? Experienced test manager Tara Roth discusses how the Microsoft Office team is working to drive the level of test coverage up during the earlier phases of product development to improve build quality later in development. Tara describes two approaches, adopted by Microsoft Office, that improved efficiency and quality-Feature Crews and Big Button. Feature Crews is a tight-knit partnership of the developer, tester, and program manager who work together on a private release of new code prior to checking it in to the main build. Big Button is an approach to having the team kick off an automated suite of tests prior to checking in to the main build.
|
Tara Roth, Microsoft Corporation
|
|
STARWEST 2008: Branch Out Using Classification Trees Classification trees are a structured, visual approach to identify and categorize equivalence class partitions for test objects. They enable testers to create better test cases faster. Classification trees visually document test requirements to make them easy to create and comprehend. Julie Gardiner explains this powerful technique and how it helps all stakeholders understand exactly what is involved in testing and offers an easier way to validate test designs. Using examples, Julie shows you how to create classification trees, how to construct test cases from them, and how they complement other testing techniques in every stage of testing. Julie demonstrates a free classification tree editing tool that helps you build, maintain, display, and use classification trees.
|
Julie Gardiner, Grove Consultants
|
|
Six Thinking Hats for Software Testers Our testing is only as good as our thinking—and all too often we are hampered by limiting ideas, poor communication, and pre-set roles and responsibilities. Based on the work of Edward de Bono, the Six Thinking Hats for software testers have helped Julian, and numerous others, work more effectively as testers and managers. The concepts are simple and easy to learn. For instance, we can use these concepts as individuals performing reviews and while testing and in groups during team meetings. Each of the six hats has a color representing a direction of thinking—the blue hat provides the overview and helps to keep us productive, the white hat helps us to collect facts, the red is a way to express intuition and feelings without having to justify them, the yellow hat seeks the best possible outcome, the black hat helps us to discover what might go wrong—not only with the software but also with our tests and our assumptions!
|
Julian Harty, Google
|
|
STARWEST 2008: Telling Your Exploratory Story What do you say when your manager asks, "How did it go today?" As a test manager, you might say, "I'll check to see how many test cases the team executed today." As a tester with a pile of test cases on your desk, you could say, "I ran 40 percent of these tests today," or "At the rate I'm going I'll be finished with these test cases in 40 days." However, if you're using exploration as part of your testing approach, it might be terrifying to try to give a status report--especially if some project stakeholders think exploratory testing is irresponsible and reckless compared to test cases. So how can you retain the power and freedom of exploration and still give a report that earns your team credibility, respect, and perhaps more autonomy? Jon Bach offers ways for you to explain the critical and creative thinking that makes exploratory testing so powerful.
|
Jon Bach, LexisNexis
|
|
Testing Lessons from Springfield-Home of the Simpsons Over the years, Rob Sabourin has discovered testing lessons in the Looney Tunes gang, the Great Detectives, and Dr. Seuss. Now he turns his attention to the Simpsons, a primetime cartoon television show entertaining audiences since 1989. Rob believes that Matt Groening's popular characters can teach us important lessons about software testing. Homer's twisted ideas tell us about test automation--why it works and why it fails. Could your software stand up to Bart's abuse? Lisa Simpson, the brilliant but neglected middle child, provides a calming influence on projects. Apu, the Kwik-E-Mart operator, works 100 hours a week--should you? When is Montgomery Burn’s authoritarian management style effective? And can we bribe stakeholders as easily as Police Chief Wiggum takes a donut? Inside this simple cartoon are lessons on personas, context, organization, ethics, situational leadership, and motivation.
|
Robert Sabourin, AmiBug.com Inc
|
|
The Abolition of Ignorance The testing profession isn't easily mastered, and isn't something that can be perfected by practice alone. Good testers study testing to improve their knowledge of the areas they know about, but great testers strive to find out about areas of software testing they don't yet realize they don't know about.
|
|
|
Lessons Learned in Close Quarters Combat Few would think that the tactics employed by military and law-enforcement Special Forces to breach buildings under siege bears any relation to software project teams. After a number of weekends training with ex-military and ex-law-enforcement Special Forces—just for fun—Antony Marcano draws a surprising parallel between the dynamics of modern Special Forces "room-clearing" methods and the dynamics of modern software development teams.
|
|
|
The Key to Good Interviewing The foundation of any successful assessment is interviewing a diverse cross section of the staff. But asking the right questions and asking those questions right makes all the difference in the quality of information you can elicit from your interviewees.
|
|
|
A Map by Any Other Name A mapping illustrates a relationship between two things. In testing, a map might look like a road map, but it might also look like a list, a chart, a table, or a pile of stories. We can use any of these to help us think about test coverage.
|
|
|
Google Web Toolkit: Writing Ajax Applications Test First In part two of the series, Daniel introduces Google Web Toolkit's testing infrastructure and demonstrates how to build an Ajax application test first.
|
|