Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems


* Includes updates to material on testing Web applications.
* Contains new coverage of testing for wireless applications.
* From the coauthor of the bestselling testing book of all time.
* Each test type is backed up with a testing example and error examples.

Read More Show Less
... See more details below
Paperback (2nd Edition)
BN.com price
(Save 23%)$45.00 List Price
Other sellers (Paperback)
  • All (19) from $1.99   
  • New (6) from $23.61   
  • Used (13) from $1.99   
Sending request ...


* Includes updates to material on testing Web applications.
* Contains new coverage of testing for wireless applications.
* From the coauthor of the bestselling testing book of all time.
* Each test type is backed up with a testing example and error examples.

Read More Show Less

Product Details

  • ISBN-13: 9780471201007
  • Publisher: Wiley
  • Publication date: 6/28/2003
  • Edition description: 2nd Edition
  • Edition number: 2
  • Pages: 676
  • Sales rank: 1,142,551
  • Product dimensions: 9.20 (w) x 7.32 (h) x 1.46 (d)

Meet the Author

HUNG Q. NGUYEN is Founder of LogiGear, a Silicon Valley softwaretesting company that helps development and IT organizations improveproduct quality through smarter testing. He is coauthor of thebestselling book Testing Computer Software (Wiley).

BOB JOHNSON has more than 20 years of software engineeringexperience, including implementing, maintaining, and testingcomputer security systems.

MICHAEL HACKETT is the cofounding partner of LogiGear, where hearchitects and delivers software testing education and coachingprograms.

Read More Show Less

Read an Excerpt

Testing Applications on the Web

Test Planning for Mobile and Internet-Based Systems
By Hung Q. Nguyen Bob Johnson Michael Hackett

John Wiley & Sons

ISBN: 0-471-20100-6

Chapter One

Web Testing versus Traditional Testing

Why Read This Chapter?

Web technologies require new testing and bug analysis methods. It is assumed that you have experience in testing applications in traditional environments; what you may lack, however, is the means to apply your experience to Web environments. To effectively make such a transition, you need to understand the technology and architecture differences between traditional testing and Web testing.


This chapter presents the application model and shows how it applies to mainframes, PCs, and, ultimately, Web/client-server systems. It explores the technology differences between mainframes and Web/client-server systems, as well as the technology differences between PCs and Web/client-server systems. Testing methods that are suited to Web environments are also discussed.

Although many traditional software testing practices can be applied to the testing of Web-based applications, there are numerous technical issues that are specific to Web applications that need to be considered.

The Application Model

A computer system, which consists of hardware and software, can receive inputs from the user, then stores them somewhere, whether in volatile memory such as RAM(Random Access Memory), or in nonvolatile memory, such as hard disk memory. It can execute the instructions given by software by performing computation using the CPU (Central Processing Unit) computing power. Finally, it can process the outputs back to the user. Figure 2.1 illustrates how humans interact with computers. Through a user interface (UI), users interact with an application by offering input and receiving output in many different forms: query strings, database records, text forms, and so on. Applications take input, along with requested logic rules, and store them in memory, and then manipulate data through computing; they also perform file reading and writing (more input/output and data storing). Finally, output results are passed back to the user through the UI. Results may also be sent to other output devices, such as printers.

In traditional mainframe systems, as illustrated in Figure 2.2, all of an application's processes, except for UI controls, occur on the mainframe computer. User interface controls take place on dumb terminals that simply echo text from the mainframe. Little computation or processing occurs on the terminals themselves. The network connects the dumb terminals to the mainframe. Dumb-terminal UIs are text-based or form-based (nongraphical). Users send data and commands to the system via keyboard inputs.

Desktop PC systems, as illustrated in Figure 2.3, consolidate all processes-from UI through rules to file systems-on a single physical box. No network is required for a desktop PC. Desktop PC applications can support either a text-based UI (command-line) or a Graphical User Interface (GUI). In addition to keyboard input events, GUI-based applications also support mouse input events such as click, double-click, mouse-over, drag-and-drop, and so on.

Client-server systems, upon which Web systems are built, require a network and at least two machines to operate: a client computer and a server computer, which serves requested data to the client computer. With the vast majority of Web applications, a Web browser serves as the UI container on the client computer.

The server receives input requests from the client and manipulates the data by applying the application's business logic rules. Business logic rules are the computations that an application is designed to carry out based on user input-for example, sales tax might be charged to any e-commerce customer who enters a California mailing address. Another example might be that customers over age 35 who respond to a certain online survey will be mailed a brochure automatically. This type of activity may require reading or writing to a database. Data is sent back to the client as output from the server. The results are then formatted and displayed in the client browser.

The client-server model, and consequently the Web application model, is not as neatly segmented as that of the mainframe and the desktop PC. In the client-server model, not only can either the client or the server handle some of the processing work, but server-side processes can be divided between multiple physical boxes or computers (application server, Web server, database server, etc.). Figure 2.4, one of many possible client-server models, depicts I/O and logic rules handled by an application server (the server in the center), while a database server (the server on the right) handles data storage. The dotted lines in the illustration indicate processes that may take place on either the client-side or the server-side. See Chapter 5, "Web Application Components," for information regarding server types.

A Web system may comprise any number of physical server boxes, each handling one or more service types. Later in this chapter, Table 2.1 illustrates some of the possible three-box server configurations. Note that the example is relatively a basic system. A Web system may contain multiple Web servers, application servers, and multiple database servers (such as a server farm, a grouping of similar server types that share workload). Web systems may also include other server types, such as e-mail servers, chat servers, e-commerce servers, and user profile servers (see Chapter 5 for more information). Understanding how your Web application-under-test is structured is invaluable for bug analysis-trying to reproduce a bug or learning how you can find more bugs similar to the one that you are seeing.

Keep in mind that it is software, not hardware, that defines clients and servers. Simply put, clients are software programs that request services from other software programs on behalf of users. Servers are software programs that offer services. Additionally, client-server is also an overloaded term; it is only useful from the perspective of describing a system. A server may, and often does, become a client in the chain of requests. In addition, the server-side may include many applications and systems including mainframe systems.

Hardware and Software Differences

Mainframe systems (Figure 2.5) are traditionally controlled environments, meaning that hardware and software are primarily supported (it does not necessarily mean that all the subcomponents are produced by the same company), end to end, by the same manufacturer. A mainframe with a single operating system, and applications sold and supported by the same manufacturer, can serve multiple terminals from a central location. Compatibility issues are more manageable compared to the PC and client-server systems.

A single desktop PC system consists of mixed hardware and software-multiple hardware components built and supported by different manufacturers, multiple operating systems, and nearly limitless combinations of software applications. Configuration and compatibility issues become difficult or almost impossible to manage in this environment.

A Web system consists of many clients, as well as server hosts (computers). The system's various flavors of hardware components and software applications begin to multiply. The server-side of Web systems may also support a mixture of software and hardware and, therefore, are more complex than mainframe systems, from the configuration and compatibility perspectives. See Figure 2.6 for an illustration of a client-server system running on a local area network (LAN).

The GUI of the PC makes multiple controls available on screen at any given time (e.g., menus, pull-down lists, help screens, pictures, and command buttons.). Consequently, event-driven browsers (in event-driven model, inputs are driven by events such as a mouse click or a keypress on the keyboard) are also produced, taking advantage of the event-handling feature offered by the operating system (OS). However, event-based GUI applications (data input coupled with events) are more difficult to test. For example, each event applied to a control in a GUI may affect the behavior of other controls. Also, special dependencies can exist between GUI screens; interdependencies and constraints must be identified and tested accordingly.

The Differences between Web and Traditional Client-Server Systems

The last two sections point out the application architecture and hardware and software differences among the mainframe, PC, and Web/client-server systems. We will begin this section by exploring additional differences between Web and traditional systems so that appropriate testing considerations can be formulated.

Client-Side Applications

As illustrated in Figure 2.7, most client-server systems are data-access-driven applications. A client typically enables users, through the UI, to send input data, receive output data, and interact with the back end (for example, sending a query command). Clients of traditional client-server systems are platform-specific. That is, for each supported client operating system (e.g., Windows 16- and 32-bit, Solaris, Linux, Macintosh, etc.), a client application will be developed and tested for that target operating system.

Most Web-based systems are also data-access-driven applications. The browser-based clients are designed to handle similar activities to those supported by a traditional client. The main difference is that the Web-based client is operating within the Web browser's environment. Web browsers consist of operating system-specific client software running on a client computer. It renders HyperText Markup Language (HTML), as well as active contents, to display Web page information. Several popular browsers also support active content such as client-side scripting, Java applet, ActiveX control, eXtensible Markup Language (XML), cascading style sheet (CSS), dynamic HTML (DHTML), security features, and other goodies. To do this, browser vendors must create rendering engines and interpreters to translate and format HTML contents. In making these software components, various browsers and their releases introduce incompatibility issues. See Chapter 10, "User Interface Tests," and Chapter 17, "Configuration and Compatibility Tests," for more information.

From the Web application producer's perspective, there is no need to develop operating-system-specific clients since the browser vendors have already done that (e.g., Netscape, Microsoft, AOL, etc.). In theory, if your HTML contents are designed to conform to HTML 4 standard, your client application should run properly in any browser that supports HTML 4 standard from any vendor. But in practice, we will find ourselves working laboriously to address vendor-specific incompatibility issues introduced by each browser and its various releases. At the writing of this book, the golden rule is: "Web browsers are not created equal."

In addition to the desktop client computer and browser, there are new types of clients and browsers, which are a lot smaller than the desktop PC version. These clients are often battery-powered, rather than wall-electric-powered as is a desktop PC. These clients are mobile devices including PDAs (Personal Digital Assistants), smart phones, and handheld PCs. Since these devices represent another class of client computers, there are some differences in the mobile application model. For simplicity, in this chapter, we will only refer to the desktop PC in the client discussion. Read Chapter 6, "Mobile Web Application Platform," for discussions on the mobile client application model.

Event Handling

In the GUI and event-driven model, inputs, as the name implies, are driven by events. Events are actions taken by users, such as mouse movements and clicks, or the input of data through a keyboard. Some objects (e.g., a push button) may receive mouse-over events whenever a mouse passes over them. Amouse single-click is an event. A mouse double-click is a different kind of event. A mouse click with a modifier key, such as Ctrl, is yet another type of event. Depending on the type of event applied to a particular UI object, certain procedures or functions in an application will be executed. In an event-driven environment, this is a type of procedure referred to as event-handling code.

Testing event-driven applications is more complicated because it's very labor-intensive to cover the testing of many combinations and sequences of events. Simply identifying all possible combinations of events can be a challenge because some actions trigger multiple events.

Browser-based applications introduce a different flavor of event-handling support. Because Web browsers were originally designed as a data presentation tool, there was no need for interactions other than single-clicking for navigation and data submission, and mouse-over ALT attribute for an alternate description of graphic. Therefore, standard HTML controls such as form-based control and hyperlinks are limited to single-click events. Although script-based events can be implemented to recognize other events such as double-clicking and drag-and-drop, it's not natural in the Web-based user interface to do so (not to mention that those other events also cause incompatibility problems among different browsers.

In Web-based applications, users may click links that generate simulated dialog boxes (the server sends back a page that includes tables, text fields, and other UI objects). Users may interact with browser-based UI objects in the process of generating input for the application. In turn, events are generated. Some of the event-handling code is in scripts that are embedded in the HTML page and executed on the client-side. Others are in UI components (such as Java applets and ActiveX controls) embedded in the HTML page and executed on the client-side. Still others are executed on the server-side. Understanding where (client- or server-side) each event is handled enables you to develop useful test cases as well as reproduce errors effectively.

Browser-based applications offer very limited keyboard event support. You can navigate within the page using Tab and Shift-Tab keys. You can activate a hyperlink to jump to another link or push a command button by pressing the Enter key while the hyperlink text, graphic, or a button is highlighted. Supports for keyboard shortcuts and access keys, such as Alt-[key] or Ctrl-[key], are not available for the Web applications running in the browser's environment, although they are available for the browser application itself. Another event-handling implication in browser-based applications is in the one-way request and submission model.


Excerpted from Testing Applications on the Web by Hung Q. Nguyen Bob Johnson Michael Hackett Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Read More Show Less

Table of Contents




About the Authors.

Part One: Introduction.

Chapter 1:Welcome to Web Testing.

Chapter 2: Web Testing versus Traditional Testing.

Part Two: Methodology and Technology.

Chapter 3: Software Testing Basics.

Chapter 4: Networking Basics.

Chapter 5: Web Application Components.

Chapter 6: Mobile Web Application Platform.

Chapter 7: Test Planning Fundamentals.

Chapter 8: Sample Application.

Chapter 9: Sample Test Plan.

Part Three: Testing Practice.

Chapter 10: User Interface Tests.

Chapter 11: Functional Tests.

Chapter 12: Server-Side Testing.

Chapter 13: Using Scripts to Test.

Chapter 14: Database Tests.

Chapter 15: Help Tests.

Chapter 16: Installation Tests.

Chapter 17: Configuration and Compatibility Tests.

Chapter 18: Web Security Testing.

Chapter 19: Performance Testing.

Chapter 20: Testing Mobile Web Applications.

Chapter 21: Web Testing Tools.

Chapter 22L Finding Additional Information.

Appendix A: LogiGear Test Plan Template.

Appendix B: Weekly Status Report Template.

Appendix C: Error Analysis Checklist: Web Error Examples.

Appendix D: UI Test-Case Design Guideline: Common KeyboardNavigation and Shortcut Matrix.

Appendix E: UI Test-Case Design Guideline: Mouse ActionMatrix.

Appendix F: Web Test-Case Design Guideline: Input Boundary andValidation Matrix I.

Appendix G: Display Compatibility Test Matrix.

Appendix H: Browser OS Configuration Matrix.


Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)