Anda di halaman 1dari 3

FEATURE A Case Study in

At a Glance: Extreme
• Shortening time-to-market
consistently, release-after-
release, will only be achieved
by embracing effective quality
practices. Here is how one
company succeeded!
by James A. Cantor and Liz Derr

Introduction development climate was chaotic… most

Spurred by business' motivation to Evolution Began in a Chaotic of the time.
decrease time-to-market in order to maxi- Environment against Ambitious
mize savings or revenue opportunity, Business Plans To embark on process improvement, a
Extreme Programming (XP) approaches Egreetings' application was based in CGI- Quality Assurance department was
have gained significant attention recently. BIN technology. This legacy application formed. Assumptions implicit in this
In this quest, without quality practices that was nearing the limits of its capacity to action were that better testing would yield
keep pace, new releases deliver defects to handle high traffic volume. Its ability to better quality and impart predictability to
customers just as quickly! accept modifications and enhancements launches. There was no specific meaning
was almost negligible. To compete, associated with "better testing". At
Egreetings was not engaged in XP. I've Egreetings had to operate on a more nim- Egreetings, it did take a QA department to
referred to these practices as "extreme" ble, easily modified application with a push for better requirements authorship,
because they afforded "continuous" more compelling presentation layer. First, application deployment, and quality veri-
acceptance testing, and provided a struc- the site needed a facelift. Next, gift order fication practices.
ture that spurred continuous dialog among processing needed to be installed to
customer, developer, and tester. enhance revenue. Then an entirely new, The department was formed two weeks
Consistently, developers had both require- rearchitected application duplicating lega- before the presentation layer redesign
ments and tests available to them before cy functionality had to be specified, project was to be launched. The project
they began to code. designed, engineered, and launched. had been under development for the prior
two months.
Here's how advanced quality practices The definition of CMM1 level 1 describes
evolved and succeeded at, organizations that have not yet embarked After launching the redesigned presenta-
a top 50 website. on process improvement. Their software tion layer, the company needed to enhance
effort can be characterized as ad-hoc, and their revenue stream by offering gift-pur-
sometimes chaotic. In such organizations, chasing capabilities. The rearchitecture
few processes are defined, and successful project commenced at about the same time
implementations can be attributed to indi- the gift order-processing project was at full
vidual effort as well as heroics. Egreetings' pace.

1 CMM is a product of the Software Engineering Institute (SEI) established by Carnegie Mellon University. It provides a maturity
model that describes an organization’s ability to achieve software launch and quality goals predictably.

6 Journal of Software Testing Professionals June 2001

Rearchitecture's goal was to provide a site
that could sustain daily content and week-
ly feature releases.

So the legacy application was to be

enhanced with additional gift functionality
while the site was being rearchitected for a
later launch. All of the new gift order func-
tionality was to be folded into the rearchi-
tected application.

Here is a timeline of the major projects

and events (Figure 1).

Referring to Figure 1, for major projects

in months 1 through 4, Egreeting's capa-
bility in getting software defined, Figure 1
Acceptance test cases were developed
designed, developed, tested, and launched
QA during months 1-4 could have been through "Intuitive Decomposition", where
could be characterized as entirely "chaot-
characterized as: test analysts ask the question, "How can I
ic" until the beginning of the gift-order
break this?" Good test analysts take pride
processing project.
• Our engineers did some testing in their ability to sense where defects will
• We used domain experts to run occur.
The legacy site Redesign Project launched
through our software
with over 80 undiscovered defects. Two
• The whole company checked out the Low-level business functions had not been
weeks after the Redesign site was
new releases specifically identified, except in the form
launched, feature releases recommenced,
• We used a test check sheet to make sure of web pages (e.g. login page, profile
and were accomplished every 1-3 weeks.
tests achieved basic functional coverage page). Acceptance test cases were docu-
One permanent and three temporary
mented based on the author's ability to
testers performed ad-hoc testing of releas-
Acceptance tests were designed intuitive- intuitively perceive the paths through the
es until midway through the 4th month.
ly, on the fly, relying on the testers' domain business function. Each path identified
expertise. Company wide testing depend- became a test case.
Subsequent to the Rearchitecture Site
ed upon the initiative of individual testers
launch, feature releases occurred semi-
during a specifically scheduled test win- Practices Applied to Single
weekly (twice per week) or weekly.
dow. And there were no requirements Projects First
Content releases occurred daily.
from which to derive test cases. Figure 3 represents the process flow dur-
ing the first four months. Classically, we
followed waterfall development and test-
ing process. Each successive step was
dependent upon the preceding step.

At the beginning of the "Gift Order

Processing" project in month 5, the large
project process matured to a semi-water-
fall model, since test cases were authored
before coding began, then continuously
revised. See figure 4. QA was beginning
to exit from the critical path.

But "adding-in" the test authorship task

was not simple! Both development and
test effectiveness depend upon and sup-
Figure 2 port good requirements, presenting a

June 2001 Journal of Software Testing Professionals 7

Testing Web and eBusiness

Managing the Software Testing

Testing & Process

Testing Object-Oriented Software

Quality Software Test Automation and

Scripting Techniques

Courses Software Inspection & Reviews:

A Process-Oriented Approach

Practical Techniques for
Software Quality Assurance

Software Requirements

Leading Exploration and Definition

Software Test Planning and Design

Industry Building the Software Quality

Assurance Funtion Step by Step

Experts Requirement-Based Testing

The International Institute for Software Testing offers all its courses at your site to maximize
learning and minimize cost to your organization.

All courses count towards the Certification of Software Test Professionals (CSTP)
For additional information visit: or call 651-306-1387