A Case Study in
Spurred by business' motivation to decrease time-to-market in order to maxi- mize savings or revenue opportunity, Extreme Programming (XP) approaches have gained significant attention recently. In this quest, without quality practices that keep pace, new releases deliver defects to customers just as quickly!
Egreetings was not engaged in XP. I've referred to these practices as "extreme" because they afforded "continuous" acceptance testing, and provided a struc- ture that spurred continuous dialog among customer,
tester. Consistently, developers had both require- ments and tests available to thembefore they began to code.
Here's how advanced quality practices evolved and succeeded at Egreetings.com, a top 50 website.
Evolution Began in a Chaotic
Environment against Ambitious
Egreetings' application was based in CGI- BIN technology. This legacy application was nearing the limits of its capacity to handle high traffic volume. Its ability to accept modifications and enhancements was almost negligible. To compete, Egreetings had to operate on a more nim- ble, easily modified application with a more compelling presentation layer. First, the site needed a facelift. Next, gift order processing needed to be installed to enhance revenue. Then an entirely new, rearchitected application duplicating lega- cy functionality had to be specified, designed, engineered, and launched.
The definition of CMM1 level 1 describes organizations that have not yet embarked on process improvement. Their software effort can be characterized as ad-hoc, and sometimes chaotic. In such organizations, few processes are defined, and successful implementations can be attributed to indi- vidual effort as well as heroics. Egreetings'
To embark on process improvement, a Quality Assurance department was formed. Assumptions implicit in this action were that better testing would yield better quality and impart predictability to launches. There was no specific meaning associated with "better testing". At Egreetings, it did take a QA department to push for better requirements authorship, application deployment, and quality veri- fication practices.
The department was formed two weeks before the presentation layer redesign project was to be launched. The project had been under development for the prior two months.
After launching the redesigned presenta- tion layer, the company needed to enhance their revenue stream by offering gift-pur- chasing capabilities. The rearchitecture project commenced at about the same time the gift order-processing project was at full pace.
release, will only be achieved
by embracing effective quality
practices. Here is how one
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.
Referring to Figure 1, for major projects in months 1 through 4, Egreeting's capa- bility in getting software defined, designed, developed, tested, and launched could be characterized as entirely "chaot- ic" until the beginning of the gift-order processing project.
The legacy site Redesign Project launched with over 80 undiscovered defects. Two weeks after the Redesign site was launched, feature releases recommenced, and were accomplished every 1-3 weeks. One permanent and three temporary testers performed ad-hoc testing of releas- es until midway through the 4th month.
Subsequent to the Rearchitecture Site launch, feature releases occurred semi- weekly (twice per week) or weekly. Content releases occurred daily.
Acceptance tests were designed intuitive- ly, on the fly, relying on the testers' domain expertise. Company wide testing depend- ed upon the initiative of individual testers during a specifically scheduled test win- dow. And there were no requirements from which to derive test cases.
Acceptance test cases were developed through "Intuitive Decomposition", where test analysts ask the question, "How can I break this?" Good test analysts take pride in their ability to sense where defects will occur.
Low-level business functions had not been specifically identified, except in the form of web pages (e.g. login page, profile page). Acceptance test cases were docu- mented based on the author's ability to intuitively perceive the paths through the business function. Each path identified became a test case.
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- port good requirements, presenting a
Now bringing you back...
Does that email address look wrong? Try again with a different email.