XP teams have the right to do their best work. On the other hand, customers have the right to specify and pay for only the quality they need. How does one reconcile two potentially conflicting points of view? Is quality negotiable? If so, how do we go about negotiating it? This paper will explore the following questions: Is quality negotiable? How can we negotiate quality? What are internal and external quality, and are either or both negotiable? What's the XP tester's quality assurance role? How far should testers go in helping the customer define acceptance criteria?
The morning I sat down to start writing this paper, my contractor called (we’re in the middle of building an addition to our house). He told me the painter would apply one coat of paint to the primed siding. If I wanted a second coat of paint, it would cost $275 extra. Higher quality often costs extra. It struck me how often we make decisions and compromises about quality in our daily lives. Shall I buy a Yugo or a Volvo? Eat at McDonald’s or go home and cook? It all depends on what I need most—money, safety, time, nutrition.
In eXtreme Programming Explained , Kent Beck describes the four variables of software development: Cost, Time, Quality and Scope. As he says, “quality is a strange variable”. If you try to save time or money, or increase scope, by sacrificing quality, you will pay a price in human, business and technical costs. XP teams have the right to do their best work.
On the other hand, customers have the right to specify and pay for the only the quality they need. How does one reconcile two potentially conflicting points of view? Is quality negotiable? If so, how do we go about negotiating it?
This paper will explore the following questions:
- Is quality negotiable?
- How can we negotiate quality?
- What are internal and external quality, and are either or both negotiable?
- What’s the XP tester’s quality assurance role?
- How far should testers go in helping the customer define acceptance criteria?
Testing, acceptance testing, quality assurance, tester, web testing, GUI testing, XP, painting houses.
When my husband and I decided to put an addition on our house, we chose to include a basement. We signed a detailed contract with our contractor which specified many little details. We thought we read this carefully. When the basement was built and a hole cut for the door, the contractor pointed out that he had neglected to include the door itself in the contract. We had access to the new basement—it was functional—just no way to close it off if we wanted. Since the door was not included, we would either have to do without it, or pay extra.
Naturally, we had assumed there would be a door to the basement room which we could open and shut. But since we had not specified this, the contractor hadn’t included the price of the door or the labor to install it in his price. We couldn’t expect the contractor to just give us a free door. How nice it would have been if someone else had looked at the contract with me and asked, “There isn’t a door specified here, don’t you want one?” Then I could have decided whether or not to spend the money—it wouldn’t have been a surprise later.
I’ve participated in XP projects where I’ve seen this type of thing happen. (OK, it happens in all software projects, no matter what practices are used). For example, the customer has a story for an add screen, and just assumes the developers know he also wants the ability to update, read and delete. Or maybe there’s a story for a login screen with authentication, but nothing about what should happen if the same user logs in twice. At the end of the iteration, an exception thrown by having the same user log in twice looks like a defect.
As a tester and quality assurance engineer of long experience, I’m something of a tyrant about quality. I have my own standards which naturally I think everyone should follow. When I started working on XP projects, I realized it wasn’t about MY quality standards—it was the customers.’