SYNOPSIS

The Definitive Guide to Quality Application Delivery focuses on the whole picture of improving quality in your applications, starting from the requirements and design phase and continuing through development and testing. Common myths are examined and dispelled, including the myth that simply purchasing software testing tools will instantly make quality better for everyone. Quality, you'll learn, is about far more than bugs. The perception of quality starts with an application's ability to efficiently solve business needs, and this book constructs a whole new approach to quality that focuses on the alignment of software with the business as a primary quality indicator. Putting the business in the "driver's seat," ending the vicious cycle of software disappointment, and sticking to a truly business-focused approach to design, development, and testing - these are the keys to quality application delivery.

CHAPTER PREVIEWS

Chapter 1: Introduction

Application development executives told Forrester that their biggest challenge for delivering new and updated in-house applications is quality (Source: Application Development Executives Need Better Visibility to Become More Reliable Business Partners, Forrester Consulting, May 2007). In the same study, 43% of those executives said that they planned initiatives to reduce application development cost. 35% planned to focus on quality improvements, and 28% planned to work on their time-to-market metrics. When it came to quality, they said their biggest problems, aside from the perennial problem of finding enough staff, were time pressures, requirements, complexity, and processes. Poor requirements have been cited as a root problem in software quality (Source: The Root of the Problem: Poor Requirements, Carey Schwaber et. al., September 2006) since time immemorial, most commonly in the infamous “scope creep” that negatively impacts so many software development projects.

You've seen it. We've all seen it. Delivering high-quality applications is incredibly difficult. Not only are applications commonly perceived by users as buggy, but they're often perceived as simply working incorrectly—meaning they don't meet their requirements. Unfortunately, there's no simple, easy button that you can push to improve software quality—despite some manager's uninformed perception that an add-on suite of software testing tools will solve the problem overnight. Instead, you'll find that the ultimate answer is a complete overhaul to the way you look at software quality, and a more mature approach to the way you develop software applications, starting at the beginning of the development project. That's what this guide is all about—examining where quality problems begin to enter a project, and defining ways to improve quality throughout the life cycle of the project.

The goal of this chapter is to provide a sort of executive overview for the entire guide. In this chapter, I'll outline the problem and the basic steps toward a solution; subsequent chapters will dive into much greater detail on these steps and help you build a clear picture of what you need to do in order to bring quality applications to your organization.

Chapter 2: What is Quality, and Who Cares?

What is application quality? Before we go any further in discussing how to achieve it, we'd better agree on what "it" is. Plenty of people think quality is an intangible, something that's difficult to define and measure because it goes beyond the measurable; others think that quality is completely measurable, if difficult to achieve. Both are right.

It's sometimes difficult to see this in action in your own environment, so to help illustrate what quality is, who cares about it, and where it goes missing in a project I'm going to share from my own experience. I've worked in a number of organizations that had major software development projects that often suffered from fairly common quality challenges; we'll use those to home in on where the problems started and how they could have been avoided. Later chapters in this guide will dive deeper into specific topics.

Chapter 3: The Costs of Quality (and the Costs of None)

“Okay,” you might be saying, “after two chapters of harping on quality—I'm sold. What'll it cost me?” An excellent question, because quality does indeed cost. In fact, it's easy for companies to get so focused on quality—or particular aspects of it—that they run their development costs up past the point where the quality pays for itself. In other words, contrary as it may seem, you can have too much quality.

Take a building as an example, and let's replace the word “quality” with “sturdy;” certainly sturdiness is one thing that people feel points to a quality building. Can you have too much sturdiness? Of course. Traditional residential construction typically uses wood framing, but are there sturdier materials? Definitely. Metal 2 × 4 construction, poured concrete, and other materials offer more strength and longer life, but they do so at a significantly higher cost. So why doesn't everyone simply go with these sturdier materials and techniques? Because in most parts of the country, that extra sturdiness doesn't actually add value to the house. Sure, in a hurricane-prone area, you might be able to easily justify the cost of extra sturdiness by weighing against the damage that hurricane winds will do to a less-sturdy home; in that case, you're offsetting the higher construction costs with demonstrably less damage and a longer structural life. Elsewhere in the country, however, the cost of that extra sturdiness isn't offset by anything, meaning your expense isn't, in the end, worth it.

So it is with software. It's easy to spend a lot of money on some aspect of quality—say, bug-free, or high-performance—but to spend more money than a lower level of quality would have cost you. Therefore, we need to talk about what quality costs—both the lack of quality, and the cost of adding more quality. With that information, we can begin to weigh those costs against one another and strike an appropriate balance.

Chapter 4: What's Your Quality Level?

It's nearly impossible to instantly go from little or no quality all the way to amazing quality; much like building a skyscraper, you have to start with a solid foundation, complete the lower levels, and only after getting everything in place underneath can you finish the top. With quality, you need to get some fundamentals in place, and learn to build an organization capable of implementing and sustaining quality in a repeatable, logical fashion. So before going any further, it'll be useful to assess your organization's current quality level so that we can decide what the next steps will be to improve that level.

The Quality Quiz

The easiest way to quickly assess your current quality level is to take a short quiz. Simply answer, as honestly as possible, each of these questions. Keep track of your answers on a separate sheet (or print the answer card in Figure 5.1, which follows the quiz), and at the conclusion, you'll create a score that points to your quality level. Choose only the best answer for each question—that is, the one answer that fits your organization the most.

1. Your organization's quality team…
   a. Doesn't exist
   b. Exists, but struggles to communicate quality
   c. We have several quality teams that don't always deliver consistent quality
   d. Exists and consistently delivers quality
   
   
2. Our quality tools…
   a. Don't exist
   b. Consist primarily of testing automation tools
   c. Include automated testing and static code analysis tools
   d. Track specific requirements and their business impact

Chapter 5: Requirements—Quality from the Beginning

If you've read the previous four chapters in this guide, you've likely gotten the message that software quality is driven first and foremost by the business-level requirements you set at the beginning of the application development process. In this chapter, we'll look at requirements in great detail, with a goal of defining and describing exactly what it is that makes a good set of requirements—and how those requirements drive application quality.

In this book's first chapter, we agreed that “bug free” is one of the first and most common criteria most people cite when asked what they consider to be a “quality application.” Defect-free software is certainly desirable, but it's not something you can actually specify in a set of requirements (of course, you can write that in your requirements—but it won't particularly help). For that reason, “bug free” is something we will not be discussing in this chapter. Instead, we're going to look at the business- and user-level requirements that lead to a quality application. Don't take the omission of bugs as a negative, however; we will definitely be looking at ways to improve application quality with respect to defects—but will be doing so in later chapters because decreasing the bug count is more a function of software design, development, and testing, rather than in requirements definition.

Chapter 6: Design—Building Quality In

At this point, we've thoroughly covered the idea that solid, well-written, business-aligned requirements are the first key to delivering a quality application. But requirements in and of themselves can't simply be turned over to a team of programmers. Requirements are missing crucial factors that developers need to get started: design decisions. For all the emphasis that I've placed on requirements thus far in this book, I need to acknowledge that requirements are purposely selfish, focusing primarily on the things the business needs. Requirements should deliberately steer clear of technical specifications, leaving that up to a design document. The design is intended to map those business requirements to technical specifications.

The design has a tremendous impact on quality. Although I feel it's of utmost importance for developers and testers to have access to the original requirements document, a well-written design should remove any real need for them to read it regularly.

In an article on Builderau.com, Robert Brogue emphasizes that designs should focus on the how, not the why:

…the answer is that you should be focusing on what must be done to complete the solution. For instance, in an e-commerce Web site, you will have to handle users forgetting their passwords. That is the "what must be done" part of the design. Obviously, the person must receive some sort of verification information via e-mail and return it to the site. As to how that is solved, cryptographically sound tokens, hashes, and the like are not a part of a high-level design. They are details best left to the detailed design or to program specifications.

As another example, if the requirement is that the system must have the ability to secure specific content, you need only describe a security mechanism, which has these requirements. You need not indicate the development of a security system based on GUIDs where all items in the system have a unique GUID that can be assigned to a user or group. The introduction of the "How" (using GUIDs) into a design document is an unnecessary addition of information that does not help the architecture or design. However, it solves your competitors need for a way to solve the problem.

The focus of a design document is on "what is needed" to satisfy the requirements (what the user wants and what the environment requires). Any other information in the design document detracts from its primary purpose (Source: http://www.builderau.com.au/strategy/architecture/soa/Application-Design-Writing-design-documents-that-cannot-be-stolen/0,339028264,320282726,00.htm).

In this chapter, we'll focus on writing design documents that not only help developers and testers understand how they need to write and test the application but also how they can do so in a quality manner.

Chapter 7: Development—Quality Practices

Let's quickly summarize where we're at on the path to better application quality: At this point, you should be clear on the idea that quality stems first from well-written application requirements and a quality-driven design. I've covered the fact that testing, while extremely important, cannot generate any quality above and beyond what's in those requirements and in your design. At its best, testing can help ensure that the quality specified in the requirements and the design is actually met.

This chapter is about the actual development process, so you might wonder why I've started with a paragraph that mentions testing twice and doesn't mention development at all. I did that largely based on my experiences with application development—developers, I've found, don't really like to test as they go, and they're often not given good guidelines or opportunities for testing as they go. I think one of the most important things developers can do to ensure better quality is to do better testing. Obviously, though, developers can also contribute additional quality by following better coding practices, and they can also ensure a better-quality application by developing directly to the design and to the requirements. That seems obvious, but sometimes in the thick of development pressures, it's easy to lose track of.

Chapter 8: Functional Testing—Verifying Quality

Automated testing cannot, by itself, add more quality to an application. That is, all an automation tool can do is make things faster and less tedious; it cannot inherently make them better. That's why this chapter will focus on testing generally and not specifically on tools. You need to have a solid testing methodology in place before you begin automating it; in other words, you need to create the desired level of quality using manual processes, and then you can begin relying on tools to help automate those processes.

Chapter 9: Performance Testing

We're approaching the end of our exploration of quality application delivery, but that doesn't mean that this chapter's topic—performance—should be considered an afterthought or somehow of lesser importance. As I've discussed in previous chapters, in fact, performance is very often the first thing that end users see that gives them a good or bad perception of the application's overall performance.

In this chapter, you will learn about application performance requirements and perceptions. You will also learn about manual and automated methods to test application code performance. Finally, this chapter discusses load testing, performance testing and tuning, and specific goals you can use to measure application performance.

Chapter 10: Quality Application Delivery

In this chapter, I'd like to reflect on some of the major points we've covered. I'd also like to provide some real next-step actions that you can take in your environment to start immediately improving application quality and to start tracking your progress toward increasingly-better application quality. I'll focus especially on how tools—once you've adopted an attitude and environment of quality within your organization—can help expedite the process of creating higher-quality applications.

Finding Lost Quality

Let's review: Where is quality lost? What hurdles must project teams overcome in order to achieve better application quality? What areas of the project life cycle deserve the most attention, and what specific activities can be improved upon to introduce more quality into the project? Although lost quality is often detected most easily in testing, testing is rarely where the quality is actually lost. In fact, although testing can often detect a wide range of missing quality-bugs, poor performance, bad security, and so forth—many of these are not fixable (without essentially starting over to some degree), so it pays to catch the lost quality as early as possible.