ZAP Mercury Agile Modeling With QC

8/8/2019 ZAP Mercury Agile Modeling With QC

1/12

MANAGING QUALITY IN AGILE PROJECTSWITH MERCURY QUALITY CENTER


2/12

Executive Summary............................................................................... 2

Background: Agile Software Development ............................... 3

Agile Methods vs. Traditional Development

Approaches ........................................................................................... 3

Its all About Rapid Prototyping .................................................. 4

Mapping Test Cases Back to Prototypes ............................... 5

How to Deliver and Manage Quality in Agile

Development Shops .............................................................................. 5

Four Major Requirements for QA Solutions

in an Agile Environment.................................................................. 5

Overview: Mercury Quality Center 9.0 for

Agile Software Engineering .......................................................... 6

Summary ..................................................................................................... 11

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

TABLE OF CONTENTS

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 cycledesign,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.

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


3/12

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 methodscreated prior to

2000include 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 customersthe 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.

Ale methos s. Tatonal deeloent Aoaches

Agile vs. Iterative Development

Most agile methods share iterative developments 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 artifactsrequirement 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 cyclea 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 adaptationan 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.

Aate ethosfocus 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.

pecte ethos 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.


4/12

Adaptability is a key reason why agile development processes are

being adopted at an ever-increasing number of enterprisesas

shown in the illustration aboveand why agile methods are being

embraced by increasingly large organizations today.

its all Abot ra pototn

One of the key advantages of agile software development is the

ability to rapidly prototype what is being developed.

Prototyping is the process of quickly putting together a working

model in order to test various aspects of the design, illustrate ideas

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 theyre even used to generate code (often a good thing). Each of these models canbe 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.

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

1-1 1-2Are you aware of agile softwaredevelopment processes?

How interested are you in adopting

agile software development processes?

Already using

14%

Aware

38%

Not aware

48%

Somewhat

interested

29%

Not interested

51%

Very intersted but

no plans to adopt

12%

Will pilot in the

next 12 months

8%

Base: 911 software and services decision-makers

at North American and European enterprises

Base: 346 software and services decision makers and

North American and European enterprises that are

aware of but not already using agile

Accon to the Ale manfesto, tten b onent

softae ennees, ale ethos ehasze:

Individualsandinteractions oe ocesses an tools

Workingsoftware oe coehense ocentaton

Customercollaboration oe contact neotaton

Respondingtochange oe follon a lan


5/12

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.

man Test Cases Bac to pototes

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

and the design of the application GUI.

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

Ste # Ste desctons Execte reslts

1. Invoke login page through browser [http://zap-t.com] Login page invoked with label ZAP-T.com Login

. Type user name [zaptechnologies]

Type password [mercury2006]

Click LOGIN button

Home page displayed

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 becomea 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.

Fo majo reqeents fo QA Soltons n an Ale Enonent

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

Ablt to sot rAd (a alcaton eeloent): 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.

Ablt to efne test cases at hh leels of abstacton: 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-te collaboaton th eeloes oe efects: 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.

Ablt to tace ata eleents to test case exectons: 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.

In prototyping, the login procedure testers can easily design test cases that will address the requirements

of the future software.


6/12

Oee: mec Qalt Cente 9.0 fo Ale Softae Enneen

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 processesand

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 theability 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 Centers 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.

Mercury Quality Centers software testing process.

MERCURY QUALITY CENTER

REPORTS AND ANALYSIS

Define Test

Requirements

Develop

Test Plan

Execute

Tests

Track

Defects


7/12

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.0and an excellent

testing solution for agile teamsis 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 soonerduring system designaccelerating time-to-deployment for high-

quality software

Mercury Quality Center centralizes the testing environment.

APPLICATION A

VIEW PROJECTS

FROM DIFFERENT

LOCATIONS RECEIVE TEST DATA AND

ANALYZE RESULTS

WEB SERVER

APPLICATION B

APPLICATION C

USA

POOLED

TESTING

RESOU

RCES

ASIA

EUROPE

SIMULTANEOUS

BROWSER-BASED

TESTING OF ONE OR

MORE PROJECTS

C

B

A

CUSTOMERS CENTRALIZED TESTING ENVIRONMENT


8/12

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 its 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 casesbusiness process

tests in order to perform certain AUT business procedures.

Lets 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 Centers 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


1. Invoke login page through browser [http://zap-t.com] Login page invoked with label ZAP-T.com Login


9/12

9

LOgiN AuT BuSiNESS COmpONENT


1. Type user name [zaptechnologies]

Type password [mercury2006]

Click LOGIN button

Home page displayed

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.


10/12

1 0

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 doesnt 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 doesnt 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.


11/12

1 1

The illustration to the right summarizes the agile approach to managing requirements,

reflecting extreme programming (XP)s planning routine. Your software development

team has a stack of prioritized and estimated requirements that needs to be

implementedXP developers will literally have a stack of user stories written on

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.

SummAry

In its highest form, software engineering is a team sport. Today, enterprises of

all types and sizes are embracing agile development methods because they

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.

Mercury Quality Center facilitates the use of agile methods, making it the platform

of choice for agile projects. Mercury products are designed for collaboration and

flexibility, and Mercurys track record with lifecycle quality management translates

to sophisticated, comprehensive tools for delivering and managing high-quality

applications.

ABOuT THE AuTHOrS

Alex Chena

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 ZAProcessa 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.

matthe moan

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.

The agile approach to managing requirements.

REQUIREMENTS

HIGH

PRIORITY

LOW

PRIORITY

EACH NEW

REQUIREMENT

PRIORITIZED AND

ADDED TO THE

STACK

REQUIREMENTS

MAY BE

PRIORITIZED AT

ANY TIME

REQUIREMENTS

MAY BEREMOVED AT

ANY TIME


12/12

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

Documents

ZAP Mercury Agile Modeling With QC