Tài liệu Java Testing and Design- P3 ppt

Modeling User Behavior for Meaningful Test Results 79

Testing Web-enabled applications plays an important role in solving busi￾ness issues for a company. By recognizing how tests can solve business issues,

the test professional learns valuable answers to important questions.

Over the years I learned that the highest quality Web-enabled application

systems were designed to be tested and maintained. Good system design pre￾pares for issues such as these:

• How frequently will components fail? Are replacement parts on

hand? What steps are needed to replace a component?

• What are the expected steps needed to maintain the system?

For example, a data-intensive Web-enabled application will

need index and tables data to be re-created to capture unused

disk space and memory. Will the system be available to users

while an index is rebuilt?

When users put an

item in a shopping

basket, is it still there

an hour later? Did

the item not appear

in your shopping bas￾ket, but instead

appear in another

user’s shopping bas￾ket? Did the system

allow this privilege

error?

Testing to find state

and boundary prob￾lems

Unit testing with intelligent agents is

good at probing a Web-enabled

application function with both valid

and invalid data. The results show

that parts of a Web-enabled applica￾tion are not functioning correctly.

Intelligent agents automate unit

tests to streamline testing and

reduce testing costs.

How will the Web￾enabled application

operate when higher￾than-expected use is

encountered?

Testing to be pre￾pared for higher￾than-expected vol￾umes

A network of intelligent test agents

running concurrently will show how

the Web-enabled application

operates during periods of intense

overuse.

As software is main￾tained, old bugs may

find new life. What

was once fixed and is

now broken again?

Testing to find soft￾ware regression

Intelligent test agents monitor by

stepping a Web-enabled application

through its functions. When new

software is available the monitor

tests that previously available func￾tions are still working.

Table 3–1 Questions to Ask When Developing Web-Enabled Applications

PH069-Cohen.book Page 79 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

80 Chapter 3 Modeling Tests

• Where will new components be added to the system? Will more

physical space be needed to accommodate new computer

hardware? Where will new software be installed?

• What areas are expected to get better if occasionally reviewed

for efficiency and performance? We can expect improvements

in memory, CPU, and storage technology. Should the system be

planned to incorporate these improvements?

Understanding the lifecycle for developing Web-enabled applications is

integral to answering business questions and preparing for maintenance.

Lifecycles, Projects, and Human Nature

Human nature plays a significant role in deciding infrastructure require￾ments and test methodology. As humans we base our decisions on past expe￾rience, credibility, an understanding of the facts, the style with which the

data is presented, and many other factors. We need to keep human nature in

mind when designing a product lifecycle, new architecture, and a test. For

example, consider being a network manager at a transportation company.

The company decides to use a Web-enabled application to publish fare and

schedule information currently hosted on an established database-driven sys￾tem and accessed by users through a call center. The company needs to esti￾mate the number of servers to buy and Internet bandwidth for its data

center. As the network manager, imagine presenting test result data that was

collected in a loose and ad-hoc way to a senior manager that has a rigid and

hierarchical style.

By understanding business management style, we can shape a test to be

most effective with management. Later in this section we define four types of

management styles and their impact on design and testing.

In my experience, the most meaningful test data comes from test teams

that use a well-understood software development lifecycle. Web-enabled

application software development is managed as a project and developed in a

lifecycle. Project requirements define the people, tools, goals, and schedule.

The lifecycle describes the milestones and checkpoints that are common to

all Web-enabled application projects.

Web-enabled applications have borrowed from traditional software devel￾opment methods to form an Internet software development lifecycle. The

immediacy of the user—they’re only an email message away—adds special

PH069-Cohen.book Page 80 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Lifecycles, Projects, and Human Nature 81

twists to traditional development lifecycles. Here is a typical Internet soft￾ware development lifecycle:

1. Specify the program from a mock-up of a Web site.

2. Write the software.

3. Unit test the application.

4. Fix the problems found in the unit test.

5. Internal employees test the application.

6. Fix the problems found.

7. Publish the software to the Internet.

8. Rapidly add minor bug fixes to the live servers.

Little time elapses between publishing the software to the Internet in step

8 and receiving the first feedback from users. Usually the feedback compels

the business to address the user feedback in rapid fashion. Each change to

the software sparks the start of a new lifecycle.

The lifecycle incorporates tasks from everyone involved in developing a

Web-enabled application. Another way to look at the lifecycle is to under￾stand the stages of development shown here:

• Write the requirements.

• Validate the requirements.

• Implement the project.

• Unit test the application.

• System test the application.

• Pre-deploy the application.

• Begin the production phase.

Defining phases and a lifecycle for a Web-enabled application project may

give the appearance that the project will run in logical, well conceived, and

proper steps. If only the senior management, users, vendors, service provid￾ers, sales and marketing, and financial controllers would stay out of the way!

Each of these pull and twist the project with their special interests until the

project looks like the one described in Figure 3–1.

The best-laid plans usually assume that the development team members,

both internal and external, are cooperative. In reality, however, all these constit￾uents have needs and requirements for a Web-enabled application that must be

addressed. Many software projects start with well-defined Web-enabled appli￾PH069-Cohen.book Page 81 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

82 Chapter 3 Modeling Tests

cation project phases, but when all the project requirements are considered, the

project can look like a tangled mess (Figure 3–1).

Confronted with this tangle of milestones and contingencies, software

project managers typically separate into two camps concerning the best

method to build, deploy, and maintain high-quality Web-enabled applica￾tions. One camp focuses the project team’s resources on large-scale changes

to a Web-enabled application. New software releases require a huge effort

leading to a single launch date. The other camp focuses its resources to

“divide and conquer” a long list of enhancements. Rather than making major

changes, a series of successive minor changes are developed.

Software project managers in enterprises hosting Web-enabled applica￾tions that prefer to maintain their software by constantly adding many small

improvements and bug fixes over managing toward a single, comprehensive

new version put a lot of stress on the software development team. The

Micromax Lifecycle may help.

Figure 3–1 Managing the complex and interrelated milestones for development of

a typical Web-enabled application has an impact on how software development

teams approach projects.

Baseline analysis

3/11/02

FS 1

FS 1

FS 1

FS 2

FS 2

FS 2

FS 2

FS 6

FFS

FS 3

FS 3

FS 3

FS 3

UI Design patterns

3/11/02

UI mockups

3/14/02

Insiders feedback

3/14/02

UI Freeze

3/18/02

UI Reviews and

approvals

3/19/02

Analyst briefing

3/11/02

Initial prototyping

3/19/02 Unit deliveries for

units 10-11-12

3/20/02

System script

language porting

3/28/02

Pretesting

4/1/02

Meta modeling

comparison and

unit test

3/25/02

External Test

4/3/02

Ship it!

4/4/02

Parkland committee

review

3/11/02

Structural overview

analysis

FS 1 3/14/02

FS 3

PH069-Cohen.book Page 82 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

The Micromax Lifecycle 83

The Micromax Lifecycle

Micromax is a method used to deploy many small improvements to an existing

software project. Micromax is used at major companies, such as Symantec and

Sun Microsystems, with good results. Micromax defines three techniques: a

method to categorize and prioritize problems, a method to distribute assign￾ments to a team of developers, and automation techniques to test and validate

the changes. Project managers benefit from Micromax by having predictable

schedules and good resource allocation. Developers benefit from Micromax

because the projects are self-contained and give the developer a chance to buy-in

to the project rather than being handed a huge multifaceted goal. QA technicians

benefit by knowing the best order in which to test and solve problems.

Categorizing Problems

Micromax defines a method for categorizing and prioritizing problems.

Users, developers, managers, and analysts may report the problems. The goal

is to develop metrics by which problems can be understood and solved. The

more input the better.

Problems may also be known as bugs, changes, enhancement requests,

wishes, and even undocumented features. Choose the terminology that

works best for your team, including people outside the engineering group. A

problem in Micromax is a statement of a change that will benefit users or the

company. However, a problem report is categorized according to the effect

on users. Table 3–2 describes the problem categories defined by Micromax.

Table 3–2 Micromax Problem Categories

Category Explanation

1 Data loss

2 Function loss

3 Intermittent function loss

4 Function loss with workaround

5 Speed loss

6 Usability friction

7 Cosmetic

PH069-Cohen.book Page 83 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.