MANAGING QUALITY IN AGILE PROJECTS

WITH MERCURY QUALITY CENTER

EXECUTIVE SUMMARY

Agile software development is a conceptual framework for software engineering that is rapidly gaining
momentum in enterprises of all types and sizes. Agile development processes are now in use at 14
percent of North American and European enterprises, and another 19 percent of enterprises are either
interested in adopting agile or already planning to do so.*

The agile framework is gaining traction because it helps development teams accelerate product
releases and improve product quality at the same time. Using agile principles, developers can conduct
code-build-test cycles more frequently and identify integration problems earlier in the development
process.

Mercury Quality Center™ has emerged as the platform of choice for managing the quality of agile
development projects. Software engineering with agile is a team effort, and Mercury Quality Center
is specifically designed for collaborative engineering across the entire development cycle—design,
testing, editing, change management, and ongoing maintenance.

This paper describes the key principles of the agile framework and illustrates why Mercury Quality
Center is particularly well suited for managing quality in agile development projects.

*Source: November 30, 2005, Corporate IT Leads the Second Wave of Agile Adoption, by Carey Schwaber with Richard Fichera, Forrester

TABLE OF CONTENTS
Executive Summary................................................................................ 2 How to Deliver and Manage Quality in Agile
Development Shops............................................................................... 5
Background: Agile Software Development................................ 3
Four Major Requirements for QA Solutions
Agile Methods vs. Traditional Development
in an Agile Environment.................................................................. 5
Approaches............................................................................................ 3
Overview: Mercury Quality Center 9.0 for
It’s all About Rapid Prototyping................................................... 4
Agile Software Engineering........................................................... 6
Mapping Test Cases Back to Prototypes................................ 5
Summary...................................................................................................... 11

About the Authors................................................................................... 11


Background: Agile Software Development
Agile software development has its roots in rebellion. In the mid-1990s, many developers were becoming frustrated with so-called “heavyweight”
methods, typified by the bureaucratic, micro-managed, regulated use of traditional models such as the waterfall method. Heavyweight methods
often interfered with progress and stifled innovation.

Initially, agile methods were called “lightweight methods.” In 2003, a group of prominent developers formed the agile Alliance, a non-profit
organization that promotes agile development.

Agile is not a single method but a framework that can be implemented using a variety of methods. Early agile methods—created prior to
2000—include Scrum (in management), Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development, and
DSDM. Extreme Programming, or XP (unrelated to Microsoft XP), is most closely associated with agile development today. XP is extreme in the
sense that it takes 12 well-known software development best practices to their logical extremes.

Most agile methods develop software in short “timeboxes” or iterations that typically last one to four weeks. Each iteration includes all of the
tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation.
At the end of each iteration, the team reevaluates project priorities.

Agile methods emphasize realtime communication, preferably face-to-face, over written documents. Most agile teams include all the people necessary
to finish the software. At a minimum, this includes programmers and their “customers”—the people who define the product. They may be product
managers, business analysts, or actual customers. The team may also include testers, interaction designers, technical writers, and managers.

Agile Methods vs. Traditional Development Approaches

Agile vs. Iterative Development
Most agile methods share iterative development’s emphasis on building releasable software in short time periods. Agile methods differ from
iterative methods in that their time period is measured in weeks rather than months and work is performed in a highly collaborative manner.
Agile vs. the Waterfall Model
Agile development has less in common with the waterfall model. The waterfall model is the most predictive of the methodologies, stepping
through requirements capture, analysis, design, coding, and testing in a strict, pre-planned sequence. Progress is generally measured in terms
of deliverable artifacts—requirement specifications, design documents, test plans, code reviews, etc.

The waterfall model can result in a substantial integration and testing effort toward the end of the cycle—a time period typically extending from
several months to several years. The size and difficulty of this integration and testing effort is one cause of waterfall project failure. Agile methods,
in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks or months. The emphasis
is on obtaining a crude but executable system early, and continually improving it.

Some agile teams use the waterfall model on a small scale, repeating the entire waterfall cycle in every iteration. Other teams, most notably
extreme programming teams, work on activities simultaneously.
Agile vs. “Cowboy Coding”
It is important to note that agile methods are not “cowboy coding” or undisciplined hacking. There is a perception in some circles that since agile
methods rely on intra-team communication and often produce very little written documentation, they increase risk in an enterprise environment.
To the contrary, agile methods can help decrease risk in software development projects. The lack of documentation reflects an openness to
change and adaptation—an ability to react quickly to new requirements.

A more accurate distinction is to say that methods exist on a continuum from “adaptive” to “predictive,” and that agile methods exist on the
“adaptive” side of this continuum.

• Adaptive methods focus on adapting quickly to changing realities. An adaptive team will have difficulty describing exactly what will happen in the
future. An adaptive team can report exactly what tasks are scheduled to be done next week, but only which features are planned for next month.

• Predictive methods focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the
entire length of the development process. However, predictive teams have difficulty changing direction. Predictive teams will often institute a
change control board to ensure that only the most valuable changes are considered.


 1-1 “Are you aware of agile software 1-2 “How interested are you in adopting
development processes?” agile software development processes?”
Will pilot in the
next 12 months
Already using
8%
14% Very intersted but
no plans to adopt
12%

Aware Not interested

38% 51%

Somewhat
interested
Not aware 29%
48%
Base: 911 software and services decision-makers Base: 346 software and services decision makers and
at North American and European enterprises North American and European enterprises that are
aware of but not already using agile

*Source: November 30, 2005, Corporate IT Leads the Second Wave of Agile Adoption, by Carey Schwaber with Richard Fichera, Forrester

Adaptability is a key reason why agile development processes are

being adopted at an ever-increasing number of enterprises—as
shown in the illustration above—and why agile methods are being According to the “Agile Manifesto,” written by prominent
embraced by increasingly large organizations today. software engineers, agile methods emphasize:

It’s all About Rapid Prototyping • Individuals and interactions over processes and tools
One of the key advantages of agile software development is the
• Working software over comprehensive documentation
ability to rapidly prototype what is being developed.
• Customer collaboration over contract negotiation
Prototyping is the process of quickly putting together a working
model in order to test various aspects of the design, illustrate ideas • Responding to change over following a plan
or features, and gather early user feedback. It is an integral part of
the development process because it helps reduce project risk and
cost. Often one or more prototypes can be made in a process of
incremental development, where each prototype is influenced by the performance of previous designs. In this way problems or deficiencies in
design can be corrected. When the prototype is sufficiently refined and meets the functionality, robustness, manufacturability, and other design
goals, the product is ready for production.

The process typically begins with requirements collection, followed by user evaluation, followed by the creation of a prototype. The end users
evaluate the prototype, and another prototype is built based on their feedback. The cycle continues: feedback from the user is followed by a new
mock-up, the new version is tested, users provide additional feedback, and the project continues to iterate.

In many organizations the traditional approach to modeling is to develop detailed models before coding begins. Sometimes these models are
kept up to date, sometimes they are not, and sometimes they’re even used to generate code (often a good thing). Each of these models can
be created by a single, expert person who typically spends most of their time working alone. There is often a requirements/business analyst who
elicits requirements from stakeholders and then captures the information in a requirements document. This document is provided to the architect
who develops a high-level architecture model. The model is then used by the designer(s) who create detailed design model(s), which in turn
are provided to the programmers who may or may not actually follow them.

This approach to modeling sounds good in theory, but typically results in a lot of documentation being written, which for the most part is ignored
during the actual development process.


With agile, the modeling process is collaborative and iterative. You
model just enough for the goal at hand because you know you can
come back to the model later if you need to. Most models are built
to be temporary and kept only if they are needed. Stakeholders work
closely together, using inclusive modeling techniques and simple
but effective tools.

Mapping Test Cases Back to Prototypes

For a long time, agile modeling presumed testing was performed
by developers on the unit level. Recently, a new trend has emerged
in which the tester is involved as an active member of the team.
Business-process-driven testing techniques now allow test cases
to be mapped to the software prototypes. Pictures of the prototypes
developed on the white board allow the tester to start developing
test-cases right away, adhering to both the application requirements
In prototyping, the login procedure testers can easily design test cases that will address the requirements
and the design of the application GUI. of the future software.

A simple test case for the login functionality in the figure above would look something like this:

Step # Step Descriptions Expected Results

1. Invoke login page through browser [http://zap-t.com] Login page invoked with label “ZAP-T.com Login”
2. • Type user name [zaptechnologies] Home page displayed

• Type password [mercury2006]

• Click LOGIN button

Developing test cases during the prototyping phase of the agile-based development process accelerates time-to-value of the testing process.
The first iteration of the software is released ready for testing.

How to Deliver and Manage Quality in Agile Development Shops

The accelerated pace of software development using agile methods offers no benefit if teams cannot manage quality. Therefore, QA has become
a major focus in the evolution of agile software engineering. This section discusses the key requirements for QA solutions in an agile environment
and the specific advantages of Mercury Quality Center for managing application quality.

Four Major Requirements for QA Solutions in an Agile Environment

The fast pace and high adaptability of agile methods place special requirements on QA. The key capabilities a QA solution must deliver include:

• Ability to support RAD (rapid application development): As already discussed, agile is all about rapid prototyping; however, the traditional
test case development methods applicable mostly to waterfall modeling (presuming detailed requirements are outlined prior to the design
of test cases) can be very difficult to use in agile development. There needs to be a way to accelerate test case development to match the
speed of the prototyping.

• Ability to define test cases at “high levels” of abstraction: In agile modeling, requirements are outlined in high levels of abstraction, so
there needs to be a way to design manual test cases that can address this approach. At the same time, manual test cases should be capable
of being automated in order to generate maximum ROI from QA practices.

• Real-time collaboration with developers over defects: When testing agile modeling, real-time collaboration among the development group
is required. As mentioned earlier, agile development is very fast-paced programming, but bugs still need to be found and tracked, and it is
critical to be able to communicate defects back to developers.

• Ability to trace data elements to test case executions: If you ever have been involved in test execution you will agree that test data
is another critical element to be considered. When testing with agile it is very important to be able to trace test data elements during the
execution of either manual or automated scripts.


 MERCURY QUALITY CENTER
REPORTS AND ANALYSIS

Define Test Develop Execute Track

Requirements Test Plan Tests Defects

Mercury Quality Center’s software testing process.

Overview: Mercury Quality Center 9.0 for Agile Software Engineering

Mercury Quality Center provides a complete, web-based, integrated system for automated software quality testing and management across a
wide range of application environments. It provides the visibility needed to validate both functionality and automated business processes—and
identifies bottlenecks in production that stand in the way of business outcomes. It includes Mercury TestDirector for Quality Center™, Mercury
Business Process Testing™, Mercury QuickTest Professional™, Mercury WinRunner™, and Mercury Application Delivery Dashboard™, complemented
by services and support.

Mercury Quality Center enables agile teams to engage in application testing even before the development process is complete, facilitating the
ability to accelerate release schedules while ensuring the highest level of quality.

With Mercury Quality Center, you can:

• Make go-live decisions with confidence

• Standardize and manage the entire quality process

• Reduce application deployment risk

• Improve application quality and reliability

• Manage application change impact through manual and automated functional testing

• Ensure quality in strategic sourcing initiatives

• Warehouse critical application quality project data

Mercury Quality Center’s software testing process starts with outlining test requirements. Next, a test plan is developed, along with test cases
that are linked to the requirements through the creation of test sets (groups of test cases) that target a particular testing goal. The test sets are
executed and defects are identified and tracked during execution.
Advantages for Collaborative Development and QA
Mercury Quality Center is an excellent tool for agile QA because it is specifically designed to facilitate the type of collaboration and cross-
pollination key to agile software engineering.

Since Mercury Quality Center utilizes web-based technology, it allows for remote collaboration among all parties of an agile development group.
This is particularly important for agile teams. Because of the rapid development process, agile developers and other team members must work
closely together, but to have them all at the same physical location for the length of the project can be inconvenient and prohibitively expensive.
Using web-based technology like Mercury Quality Center eliminates the geographical boundaries.


 A APPLICATION A

C
APPLICATION B
VIEW PROJECTS SIMULTANEOUS
FROM DIFFERENT BROWSER-BASED
LOCATIONS TESTING OF ONE OR RECEIVE TEST DATA AND
MORE PROJECTS ANALYZE RESULTS

PO STIN CES
TE OUR APPLICATION C

USA
OL G
RE

ED
S

EUROPE

ASIA

WEB SERVER

CUSTOMER’S CENTRALIZED TESTING ENVIRONMENT

Mercury Quality Center centralizes the testing environment.

Advantages for Requirements Management

Mercury Quality Center allows rapid outlining for application under test (AUT) requirements, utilizing its Microsoft Excel or Microsoft Word importing
functionalities.

With agile AUT, requirements may be prioritized using predefined priority values,
saving time. Mercury Quality Center also provides history-tracking functionalities,
further simplifying requirements change management. In addition, Mercury Quality
Center allows the attachment of pictures of the white-board-drawn sketches to the
outlined AUT requirements, which is useful in agile development, a very picture-
friendly methodology.
Mercury Business Process Testing for Agile Projects
It is very important when testing with agile to be effective and economical in
designing test cases. However, utilizing the most common QA tools such as
Microsoft Excel and Microsoft Word makes it very difficult to implement modularity
in your agile-based test architecture, and it can be especially difficult to update test
cases rapidly when the requirements change.

One of the most advanced modules of Mercury Quality Center 9.0—and an excellent
testing solution for agile teams—is Mercury Business Process Testing.

Mercury Business Process Testing:

• Greatly simplifies and speeds up the test design process with a groundbreaking innovation called “components” (business process building
blocks)

• Allows QA/testing teams to start the test design process much sooner—during system design—accelerating time-to-deployment for high-
quality software


• Generates automated tests and test case documentation in a single step, saving a significant amount of test automation work

• Enables QA teams to use pre-packaged test assets and best practices to implement test automation for leading Enterprise Resource Planning
(ERP) and Customer Relationship Management (CRM) applications, saving time and leveraging the experience of experts

• Raises the adoption rate for test automation because it’s easy to deploy and use

Specifically, Mercury Business Process Testing allows agile testing teams to design test cases in small reusable pieces based on particular AUT
business functionality (business components). These components can be called as test steps in the procedural test cases—business process
tests in order to perform certain AUT business procedures.

Let’s consider our previous example of login functionality of ZAP-T.com using Mercury Business Process Testing.

During the prototyping session the test engineer was taking requirements notes in Microsoft Excel format.

Then, using Mercury Quality Center’s Microsoft Excel add-in, the test engineer imports this data to the Mercury Quality Center Requirements
Manager, assigning priority and attaching the snapshots of the white board sketches and other pictures.

Next, the test engineer could use Mercury Business Process Testing to design two manual business components: Invoke AUT and Login:

Invoke AUT Business Component

Step # Step Descriptions Expected Results
1. Invoke login page through browser [http://zap-t.com] Login page invoked with label “ZAP-T.com Login”


Login AUT Business Component
Step # Step Descriptions Expected Results
1. • Type user name [zaptechnologies] Home page displayed

• Type password [mercury2006]

• Click LOGIN button

Once the business components are developed, the test engineer can create a business process test of the ZAP-T.com Login functionality using
the newly developed business components.

The test engineer can link each business process test to its corresponding requirement in order to establish testing traceability.

It is very important to mention data management in testing software developed using agile methods. Mercury Business Process Testing, unlike
traditional testing methods, offers very flexible parameterization functionalities. It is possible to substitute fixed values on input and output data
that we use in our test cases with parameter names that will take on different values each time we execute them.


All of the above procedures for creating and managing requirements and test cases using Mercury Quality Center can be done in less than
one hour. And the time savings is compounded by the flexibility of Mercury Quality Center. For example, if the requirements of ZAP-T.com Login
functionality change, the test engineer doesn’t need to recreate test cases and chains that use these test cases, but must only change the priority
value of the requirement and update the business component, as shown below.

Using this approach, the test engineer doesn’t need to update business process test cases or the predefined test sets in the Test Lab module
of Mercury Quality Center.
Change Management using Mercury Quality Center
Agile software development teams embrace change, accepting the idea that requirements will evolve throughout a project. Agile team members
understand that because requirements evolve over time, any early investment in detailed documentation will only be wasted. Instead, agile team
members do just enough initial modeling to identify their project scope and develop a high-level schedule and estimate. During development,
the team will model in a just-in-time manner to explore each requirement in the necessary detail.

Because requirements change frequently, a streamlined, flexible approach to requirements change management is required. Agile team
members want to develop software that is both high-quality and high-value, and the easiest way to develop high-value software is to implement
the highest-priority requirements first. Agile team members strive to truly manage change, not prevent it, enabling them to maximize stakeholder
investment.

10
The illustration to the right summarizes the agile approach to managing requirements,
reflecting extreme programming (XP)’s planning routine. Your software development EACH NEW
team has a stack of prioritized and estimated requirements that needs to be HIGH REQUIREMENT
PRIORITIZED AND
implemented—XP developers will literally have a stack of user stories written on PRIORITY ADDED TO THE
STACK
index cards. The team takes the highest-priority requirements from the top of the
stack that they believe they can implement within the current iteration. Any change
to a requirement being currently implemented should be treated as just another new
requirement.

REQUIREMENTS
Summary REQUIREMENTS
In its highest form, software engineering is a team sport. Today, enterprises of MAY BE
PRIORITIZED AT
all types and sizes are embracing agile development methods because they ANY TIME
emphasize teamwork over individual contribution and agility over rigidity. Using the
agile framework, companies are achieving faster time-to-market for new software—
and higher quality at the same time. The net result is more productive software
teams, software that meets end-user and customer goals more completely, lower risk
for new software projects, and higher morale among software engineering teams.
REQUIREMENTS
Mercury Quality Center facilitates the use of agile methods, making it the platform LOW MAY BE
REMOVED AT
of choice for agile projects. Mercury products are designed for collaboration and PRIORITY ANY TIME
flexibility, and Mercury’s track record with lifecycle quality management translates
to sophisticated, comprehensive tools for delivering and managing high-quality
The agile approach to managing requirements.
applications.

About the Authors

Alex Chernyak
Alex Chernyak is chief technology officer and co-founder of ZAPtechnologies.com, a consulting firm specializing in business technology
optimization. Prior to founding ZAP in 1999, he had extensive experience leading professional services organizations for companies including
PowerNet and IONA Technologies.

Chernyak recently authored ZAProcess—a process for implementing software QA practices utilizing Mercury Quality Center and Mercury
QuickTest Professional. He has subsequently authored a number of articles and white papers on topics around functional test automation and
test management.

A long-time member of the Mercury Professional Services Organization, Chernyak is also a member of the Mercury Functional Testing Advisory
Board, a Mercury Certified Product Specialist, Mercury Certified Product Consultant, and Mercury Certified Instructor.

Matthew Morgan
Matthew Morgan is the director of product marketing for the Mercury Quality Center and Mercury Performance Center product lines. He has more
than eight years of experience at Mercury, managing several product initiatives including Mercury QuickTest Professional, Mercury WinRunner,
and Mercury TestDirector for Quality Center. Morgan led the design and development of the new Mercury Business Process Testing product line,
a true revolution in test design and test automation. Before joining the product organization, he was responsible for building and managing the
Mercury Technical Operations team in the Southeast.

Before Mercury, Morgan managed a distributed development team at MCI Worldcom and worked in the R&D organization of Minolta QMS. He
is a recognized leader in the quality assurance market, speaking at dozens of tradeshows and conferences. Morgan has a degree in computer
engineering from the University of South Alabama.

11
 Mercury is the global leader in business technology optimization (BTO). We are committed to helping customers optimize the business outcome of IT.
WWW.MERCURY.COM

©2006 Mercury Interactive Corporation. Patents pending. All rights reserved. Mercury Interactive, Mercury, the Mercury logo, Mercury Quality Center, Mercury Application Delivery Dashboard, Mercury Business Process Testing, Mercury
QuickTest Professional, Mercury TestDirector, and Mercury WinRunner are trademarks or registered trademarks of Mercury Interactive Corporation in the United States and/or other foreign countries. All other company, brand, and product
names are marks of their respective holder. WP-1782-0506