John Ruberto, Intuit, Inc.
Today, developing software is much more complex than in the past. Our applications are no longer applications, but instead multi-tiered systems. Sometimes they are groups of systems working in concert, which we call eco-systems. The systems interface with other systems – thousands of them. Our software is no longer the product of a single team, but built by many individuals in several countries. New client platforms and browsers come to the market everyday.
In this complex world, how do we define quality? We define quality goals with an ever-increasing number of “ilities”. We perform all kinds of testing: acceptance, performance, functional, concurrency, stress, exploratory, stability, build verification and, finally, regression testing.
Given all of this complexity, it can be difficult as a quality team to make decisions:
- How should we define quality?
- Where should we invest our time and money to best assure quality?
- How do we know when we are done?
- Where should we improve our processes?
The answers to these questions lie with our ultimate quality consultants – our customers.
One of our values at Intuit is “Customers Define Quality”, and this paper will share how we interact with our customers at every stage of the lifecycle to understand their definition of quality.
The paper will describe how we include the customer in our requirements definition phase to understand the most important customer problems, generate ideas to solve those problems and to test these hypotheses instead of just relying on the opinions of HiPPOs (Highly Paid Persons with Opinions). Since errors and defects injected during the requirements phase can be the most expensive errors, investing in quality at this stage is especially productive.
We use several customer driven processes during the design and coding phases. Design for Delight goes hand-in-hand with the requirements formation & testing process, with the goal of ensuring that we build the product that solves important problems for our customers. We also introduce the customer advocacy role, usually part of the Quality Assurance team. The paper will also describe how we build customer empathy in every developer.
During the testing phase, our customers help us prioritize our testing, both manual and automated. Our customers also help us understand how they use our products, which helps guide our testing process. Finally, we involve our customers in the testing phase.
After release, the support and feedback processes allow us to react very quickly if there are customer issues, sometimes when only one customer affected. The customer feedback also helps calibrate our development and test processes and provide an even deeper understanding of our customers.
Customer Driven Quality helps focus our quality assurance activities on our most important stakeholder, our customers.
2010 Technical Paper, John Ruberto, Abstract, Paper, Slides
