Internal and External Quality | Testing Extreme Programming

In Extreme Programming Explained, Kent Beck writes, "There is a strange relationship between internal and external quality. External quality is quality as measured by the customer. Internal quality is quality as measured by the programmers."

He goes on to explain the human effect on quality: "If you deliberately downgrade quality, your team might go faster at first, but soon the demoralization of producing crap will overwhelm any gains you temporarily made from not testing, or not reviewing, or not sticking to standards."

In this light, it looks as if we should always strive for the highest standard of quality. However, this often comes at a cost. Is the customer whether an external customer, if you're an outsourcing shop, or an internal customer, representing the business willing to pay?

An important XP concept is the difference between internal and external quality. One of the reasons that members of XP teams love coming to work each morning is that they know they'll be allowed to do their best work. If you took that away, XP just wouldn't work. Internal quality tends to speed up development time; if your unit tests must always run at 100%, your programmers will be able to go faster, because they'll catch mistakes immediately. Internal quality is a given in any XP project. It doesn't cost customers more; in fact, it's saving them time and money.

External quality can be defined as a set of system features. For example:

Whenever the user makes a mistake, a user-friendly error screen appears.
It's impossible to crash the server via the user interface.
The system can handle a hundred concurrent logins.
The system will stay up 99.995% of the time.

Internal quality can be defined as a set of process attributes:

85% of unit level defects are found by automated unit tests.
80% of estimates are within 20% of actual.
90% of the stories picked for an iteration are completed, on average.
100% of projects deliver a product to the customer.

Negotiating with the customer on external quality doesn't mean skimping on acceptance tests or deliberately producing unstable code. It means the customer asks for a certain standard of quality and pays for it. If he wants a system to handle all exceptions, that should be in the story or multiple stories. For instance, story 1 says to implement this functionality; story 2 says to make the functionality work with N concurrent users hammering it.