Home About Software Quality Engineering Sponsors Contact Us SQE.com

STARWEST 2008 Keynote Presentations

Wednesday, October 1, 2008 8:45 a.m
  Testing Lessons from Springfield—Home of the Simpsons
Rob Sabourin, AmiBug.com, Inc.

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. Just like you, the people of Springfield commit to absurdly complex projects, such as the Monorail, all of which ultimately fail miserably. Join Rob in a revealing “Simpsons retrospective” loaded with tons of testing lessons from Springfield.

Learn more about Rob Sabourin
 Rob Sabourin

Wednesday, October 1, 2008 10:00 a.m.
  Telling Your Exploratory Story
Jon Bach, Quardev, Inc.

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% 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. Learn how to report your exploration so stakeholders have a better understanding and appreciation of the value of exploratory testing to your project.

Learn more about Jon Bach
Jon Bach 

Wednesday, October 1, 2008 4:30 p.m.
  Six Thinking Hats for Software Testers
Julian Harty, Google

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! Finally, the green hat enables us to find creative solutions to ideas and issues discovered with the other five hats. Come and learn how to apply the six testing hats and other “thinking skills” on your test projects.

Learn more about Julian Harty
 Julian Harty

Thursday, October 2, 2008 8:30 a.m.
  Branch Out Using Classification Trees
Julie Gardiner, Grove Consultants

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. Using the classification tree technique and tool, you keep test documentation to a minimum, more easily create and maintain regression tests, and drastically reduce test case bloat to make your test suites more usable.

Learn more about Julie Gardiner
 Julie Gardiner

Thursday, October 2, 2008 4:15 p.m.
  Has the Time for the Adversarial Organization Passed?
Gerard Meszaros, Independent Consultant

The concept of an independent test organization is considered a “best practice” by many experts in the industry. Is this degree of autonomy actually a good thing in the real world today? In such a structure, some testers can only play “Battleship” with the delivered software, shouting gleefully when they find a defect. On their first tours of Toyota’s factories, American automakers were astonished to find no “rework area.” Toyota engineers didn’t subscribe to the approach of inserting defects on the production line only to remove them later in the quality control and rework area. Yet this is exactly what the independent test group excels at! Is it time to discard this organizational model and focus on working together with developers to prevent defects in the first place? Gerard Meszaros examines the sacred concept of independent test teams based on experiences from the agile software movement and Lean production systems. Both have shown that it is possible to replace the often dysfunctional, blaming relationship between the builders and the customers with one of mutual respect and cooperation. By applying the same “whole team” model within the technology organization, Gerard proposes to build quality in from the beginning rather than trying to test it in after the fact.

Learn more about Gerard Meszaros
 Gerard Meszaros

Friday, October 3, 2008 8:30 a.m.
  Testing Microsoft Office: Experiences You Can Leverage to Drive Quality Upstream
Tara Roth, Microsoft

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 explains their successes and describes how you can apply these concepts in your organization. In addition to sharing her Microsoft Office experience, Tara describes how other Microsoft projects apply these techniques and how you can do the same.

Learn more about Tara Roth
 Tara Roth

Top of Page
Send us Your Feedback

Software Quality Engineering  •  330 Corporate Way, Suite 300  •  Orange Park, FL 32073
Phone: 904.278.0524  •  Toll-free: 888.268.8770  •  Fax: 904.278.4380  •  Email: [email protected]
© 2008 Software Quality Engineering, All rights reserved.