Conference Presentations

Proving Our Worth: Quantifying the Value of Testing

Over the years, experts have defined testing as a process of checking, a process of exploring, a process of evaluating, a process of measuring, and a process of improving. For a quarter of a century, we have been focused on the internal process of testing, while generally disregarding its real purpose-creating information that others on the project can use to improve product quality. Join Lee Copeland as he discusses why quantifying the value of testing is difficult work. Perhaps that’s why we concentrate so much on test process; it is much easier to explain. Lee identifies stakeholders for the information we create and presents a three-step approach to creating the information they need to make critical decisions. He shares key attributes of this information-accuracy, timeliness, completeness, relevancy, and more.

Lee Copeland, Software Quality Engineering
Heuristics for Rapid Test Management

Whether you are a tester or a test manager, Jon Bach believes you have little time to do the things you want to do. Even the things on your "absolutely must do" list are competing for your limited time. Jon has a list of what he calls "half-baked" ideas on how to cope. That is, these ideas are still in the oven-still being tested. In his role as a tester and manager, Jon has learned that it's not about time management; it's really about energy management-where you focus your personal energy and direct your team’s energy. Jon shares ideas that have worked for him and some that have failed: Open-Book Testing, Dawn Patrols, Tester Show-and-Tell, Test Team Feud, and Color-Aided Design. Learn how these ideas may solve your problems with test execution, reporting, measurement, and management-all at low or no cost and relatively easy to implement.

Jon Bach, Quardev, Inc.
A Test Odyssey: Building a High Performance, Distributed Team

It seemed simple enough-hire the best available technical staff that would work from home to build some great software. Along the way, the team encountered the usual problems: time zone differences, communication headaches, and a surprising regression test monster. Matt Heusser describes how Socialtext built their high-performance development and test team, got the right people on the bus, built a culture of "assume good intent and then just do it," created the infrastructure to enable remote work, and employed a lightweight yet accountable process. Of course, the story has the impossible deadlines, conflicting expectations, unclear roles, and everything you'd get in many development projects. Matt shares how the team cut through the noise, including building a test framework integrated into the product, to achieve their product and quality aims.

Matthew Heusser, Socialtext
STAREAST 2010: Service-driven Test Management

Over the years, the test manager's role has evolved from "struggling to get involved early" to today's more common "indispensable partner in project success." In the past, when "us vs. them" thinking was common, it was easy to complain that the testing effort could not be carried out as planned due to insufficient specs, not enough people, late and incomplete delivery, no appropriate environments, no tools, tremendous time pressure, etc. Martin Pol explains how today's test managers must focus on providing a high level of performance. By using a service-driven test management approach, test managers support and enhance product development, enabling the project team to improve overall quality and find solutions for any testing problem that could negatively impact the project's success.

Martin Pol, POLTEQ IT Services BV
A Deeper Dive Into Dashboards

This session is a deeper examination of how to apply dashboards in software testing.I spent several months on a project primarily building a software testing dashboard. I have learned some interesting things, including:

  • Resources for free examples
  • Tools to help build dashboards
  • The human issues
Randy Rice, Rice Consulting Services
The Myths of Rigor

We hear that more rigor means good testing and, conversely, that less rigor means bad testing. Some managers-who've never studied testing, done testing, or even "seen" testing up close-insist that testing be rigorously planned in advance and fully documented, perhaps with tidy metrics thrown in to make it look more scientific. However, sometimes measurement, documentation, and planning don't help. In those cases, rigor may require us not to do them. As part of winning court cases, James Bach has done some of the most rigorous testing any tester will do in a career. James shows that rigor is at least as dangerous as it is useful and that we must apply care and judgment. He describes the struggle in our craft, not just over how rigorous our processes should be, but what kind of rigor matters and when rigor should be applied.

James Bach, Satisfice, Inc.
Stop Guessing About How Customers Use Your Software

What features of your software do customers use the most? What parts of the software do they find frustrating or completely useless? Wouldn't you like to target these critical areas in your testing? Most organizations get feedback-much later than anyone would like-from customer complaints, product reviews, and online discussion forums. Microsoft employs proactive approaches to gather detailed customer usage data from both beta tests and released products, achieving greater understanding of the experience of its millions of users. Product teams analyze this data to guide improvement efforts, including test planning, throughout the product cycle. Alan Page shares the inner workings of Microsoft's methods for gathering customer data, including how to know what features are used, when they are used, where crashes are occurring, and when customers are feeling pain.

Alan Page, Microsoft
You Can't Test Quality into Your Systems

Many organizations refer to their test teams and testers as QA departments and QA engineers. However, because errant systems can damage-even destroy-products and businesses, software quality must be the responsibility of the entire development team and every stakeholder. As the ones who find and report defects, and sometimes carry the “quality assurance” moniker, the test community has a unique opportunity to take up the cause of error prevention as a priority. Jeff Payne paints a picture of team and organization-wide quality assurance that is not the process-wonky, touchy, feely QA of the past that no one respects. Rather, it's tirelessly evaluating the software development artifacts beyond code; it’s measuring robustness, reliability, security, and other attributes that focus on product quality rather than process quality; it’s using risk management to drive business decisions around quality; and more.

Jeffery Payne, Coveros, Inc.
Six Budget Killers for Testing Organizations

You already have taken some basic cost-cutting steps and saved your organization money. Now, you are asked to dig even deeper into your testing budget. Where should you start? You may be looking right at the areas to address and not know what you are seeing or what to do about them. Paul Trompeter explains how to take a fresh look at your existing hardware components, re-examine reliability and availability requirements, and prepare for a future scalable environment. Paul discusses how to get regulatory affairs in order, defuse the ticking storage overload bomb, and streamline testing of complex software systems. For each budget killer, you'll learn innovative ways to overcome budget challenges while maintaining an effective test organization. Discover how to slow the spending of your testing budget while increasing the return on your testing investment and, at the same time, keeping your sanity and sense of humor.

Paul Trompeter, GDI Infotech
Improving Software Testing: One Organization's Journey

In the coming years, testers will be placed under ever increasing pressure. Joachim Herschmann describes key future trends including the increasing alignment of development and test with business needs, the integration of traditionally separate disciplines, a shared responsibility for quality, and the increased use of testing technology. Joachim describes the experiences of Borland's Linz development lab as a framework for a broader discussion about these kinds of changes and their cultural impact on the organization. He describes the journey from a waterfall-based methodology to an iterative, sprint-based development approach and the integration of developers and testers into a single team of engineers. They found that agile development provided new levels of productivity and value-and posed new challenges of shortened test cycles and a need for new test skills and tools.

Joachim Herschmann, Borland Software


CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.