Introduction to QA

Somewhat understandably, expectations of the reliability of the Web and the Internet at large are still rock-bottom among its everyday users. Chances are you've had a client call you recently to say that her e-mail was down and so she might not have received anything you've sent her. Maybe you've tried to order something online recently, only to get kicked off while your credit card was being processed. Maybe your friend's ISP has been down for a couple of days and nobody in tech support seems to be able to tell him when he'll be back online again.

Scenarios like this are all too common. What is truly terrifying is that they accepted. Your client didn't sound surprised when she told you her e-mail was down. You probably didn't even curse under your breath when your online order went wrong. And your friend shrugged his shoulders and found an Internet caf downtown.

This is unique to the Internet. If you bought a new car, and it stalled on the highway just weeks later, you'd be pretty mad at your dealer. If you ordered a mocha latte before work and your barista gave you a cappuccino, you'd get mad at her and make her fix it. And if your DVD player went wrong, you'd take it back.

There are two reasons people don't get mad when the Internet doesn't work right. The first is that they reason that there's something innately complicated about the Internet, and that it must go wrong as a result. This is a non sequitur, of course; yes, the Internet is complicated, but so is your DVD player. In practice, too, the underlying infrastructure (that is, the servers, routers and so forth) of the Internet is pretty much rock solid; it's bad programmers who make things break.

The second and more crucial reason applies to those who have had previous experience with Internet application developers. Frequently, their past experiences with these agencies and individuals have been such that their expectations with present vendors have hit rock bottom. The fact of the matter is that there are few other industries in which such an explosion of dangerously underskilled labor has occurred in the past few years. This has manifested itself in both appalling freelance Web "professionals'' and some truly appalling Web agencies. Excellence is the exception rather than the rule. In effect, there are literally thousands of vendors who talk the talk but don't walk the walk.

The more cynical inference from this observation is that because your client's expectations will be low, you should aim low, too, because they're not likely to get mad at you if things go wrong. This approach, however, is not only cynical but also not commercially sensible.

Why You Should Aim High

Aiming to have a high-quality product before handing over to the client is not just about keeping the client happy; it's about maintaining your own sanity, too.

It is inevitable that your assembled system will, initially at least, be functionally defective in some way. This does not necessarily mean that it will malfunction in the traditional sense; it could be slow when real-world data is applied, or have some unforeseen business logic error. A systematic approach to quality assurance prior to handover ensures that:

• Developer time and, hence, cost spent on resolving defects is minimized through a thorough, structured approach

• The team's timely transition onto other projects can be closely adhered to

• Problems encountered during deployment can be isolated as being unrelated to the application itself

Quite apart from that, it is perhaps a question of attitude. Compare the following with one another:

• "The client's expectations are low, therefore I can underdeliver without fear of reprisal.''

• "The client's expectations are low, therefore when I overdeliver I will be seen to excel.''

It goes without saying that being seen to excel will quickly set you apart from the competition. The client's previous experience with other suppliers may have been lackluster and their expectations low as a result, but have you noticed how they have not used those other suppliers again?

Aiming high means striving for high quality. The difference between striving and achieving starts with knowing what quality means in the first place.

What is Quality?

There is some confusion over what constitutes quality in a software application. Let us return to our analogy of a family sedan. When a motoring journalist speaks of a high-quality car, he or she is probably not referring explicitly to reliability or performance per se but rather to less tangible and quantifiable factors, such as:

• The durability of the interior

• The use of expensive, solid materials such as brushed chrome

• Purely aesthetic touches, such as blue-illuminated readouts

• The firm clunk noise made when the driver slams the door shut

Quality here is not so much a single deciding factor or even anything positive; rather, it is a function of all the areas in which something could go wrong, but doesn't.

This view is supported in the approach often taken by motoring journalists when reviewing a car or inspecting it for the first time at a trade show. The repeated activation of the cup-holder mechanism, the pressing of switches, the caressing of upholstery these are the quick-and-dirty litmus tests used to assess quality. Yet none of these tests tells us anything about the car's handling, gas mileage, reliability, or annual depreciation. So why are they important?

The truth of the matter is that although you can't judge a book by its cover, you can more often than not judge a car by its interior. A car with a smoothly ejecting cup holder, tactile, chrome-tipped switches, and seamless mechanisms is almost certainly also going to enjoy superb reliability going forward. The highest-quality brands in these exterior facets BMW, Audi, Mercedes are all consistently rated among the most reliable on the road, too.

This same rule can be applied to your Web applications. Quality is not just about whether the site stays up and does what the functional specification said it would do. It's more about the little things and, inevitably, when the little things on the surface are right, the big things underneath are right, too.

Enough about cars! What makes a Web application high quality, and how is it measured?