Chapter 10

Testing Internet Applications

Just a few years ago, Internet-based applications seemed to be the wave of the future; today, the wave has arrived onshore, and customers, employees, and business partners expect companies to have a Web presence. This expectation is not limited only to business. Most churches, civic groups, schools, and governments all have Internet presences to serve their patrons.

Generally, small to medium-size businesses have simple Web pages they use to tout their products and services. Larger enterprises often build full-fledged e-commerce applications to sell their wares, from cookies to cars and from consulting services to entire virtual companies that exist only on the Internet.

Internet applications are essentially client-server applications in which the client is a Web browser, and the server is a Web or application server. Although conceptually simple, the complexity of these applications varies wildly. Some companies have applications built for business-to-consumer uses such as banking services and retail stores, while others have business-to-business applications such as supply chain or sales force management. Development and user presentation/user interface strategies vary for these different types of websites, and, as you might imagine, the testing approach varies as well.

The goal of testing Internet-based applications is no different from that of traditional applications. You need to uncover errors in the application before deploying it to the Internet and the end user. And, given the complexity of these applications and the interdependency of the components, you likely will succeed in finding plenty of errors.

The importance of rooting out the errors in an Internet application cannot be overstated. As a result of the openness and accessibility of the Internet, competition in the business-to-consumer and business-to-business arena is intense. Thus, the Internet has created a buyer's market for goods and services. Consumers have developed high expectations, and if your site does not load quickly, respond immediately, and provide intuitive navigation features, chances are that the user will find another company with which to conduct business. This issue is not confined to strictly e-commerce or product promotion sites. Websites that are developed as research or information resources frequently are maintained by advertising or user donations. Either way, ample competition exists to lure users away, thereby reducing activity and concomitant revenue.

It would seem that consumers have higher-quality expectations for Internet applications than they do for those that come shrink-wrapped. When people buy boxed software from a store or an online retailer, as long as the quality is “average,” they will continue to use them. One reason for this behavior is that they have paid for the application, so it must be a product they perceived as useful or desirable. And even a less-than- satisfactory program can't be corrected easily, so if it at least satisfies the users' basic needs, they likely will retain the program. In contrast, a poor, or even average, quality application on the Internet, will likely cause your customer to switch to a competitor's site. Not only will the customer leave your site if it exhibits poor quality, your corporate image will become tarnished as well. After all, who feels comfortable buying a car from a company that cannot build a suitable website? Like it or not, websites have become the new first impression for business. In general, consumers don't pay to access most websites, so there is little incentive to remain loyal in the face of mediocre design or performance.

This chapter covers some of the basics of testing Internet applications. This subject is large and complex, and many references exist that explore its details. However, you will find that the techniques explained in the early chapters apply to Internet testing as well. Nevertheless, because there are, indeed, functional and design differences between Web and conventional applications, we want to point out some of the particulars of Web-based application testing.

Basic E-Commerce Architecture

Before diving into testing Internet-based applications, we will provide an overview of the three-tier client-server (C/S) architecture used in a typical Internet-based e-commerce application. Conceptually, each tier is treated as a black box with well-defined interfaces. This model allows you to change the internals of each tier without worrying about breaking another tier. Figure 10.1 illustrates each tier and the associated components used by most e-commerce sites.

Although not an official tier in the architecture, the client side and its relevance are worth explaining. Most of the access to your applications occurs from a Web browser running on a computer, although many devices, such as cell phones, PDAs, game consoles, music players, pagers, and even refrigerators and automobiles, increasingly are being developed with Internet connectivity in mind. Browsers vary dramatically in how they render content from a website. As we discuss later in this chapter, testing for browser compatibility is one challenge associated with testing Internet applications. Vendors loosely follow published standards to help make browsers behave consistently, but they also build in proprietary enhancements that cause inconsistent behavior. The remainder of the clients employ custom applications that use the Internet as a pipeline to a particular site. In this scenario, the application mimics a standard client-server application you might find on a company's local area network.

The Web server represents the first tier in the three-tier architecture and houses the website. The look and feel of an Internet application comes from the first tier. Thus, another term for this tier is the presentation tier or layer, so dubbed because it provides the visual content to the end user. The Web server can use static HyperText Markup Language (HTML) pages or Common Gateway Interface (CGI) scripts to create dynamic HTML, but most likely it uses a combination of static and dynamic pages.

Tier 2, or the business layer, houses the application server. Here, you run the software that models your business processes. The following lists some of the functionality associated with the Business layer:

• Transaction processing
• User authentication
• Data validation
• Application logging

The third tier focuses on storing and retrieving data from a data source, typically a relational database management system (RDBMS). Another term for tier 3 is the data layer. This tier consists of a database infrastructure to communicate with the second tier. The interface into the data layer is defined by the data model, which describes how you want to store data. Sometimes, several database servers make up this tier. You typically tune database systems into this layer to handle the high transaction rates encountered in an e-commerce site. In addition to a database server, some e-commerce sites may place an authentication server in this layer. Most often, you use a Lightweight Directory Application Protocol (LDAP) server for this function.

Testing Challenges

You will face many challenges when designing and testing Internet-based applications due to the large number of elements you cannot control and the number of interdependent components. Adequately testing your application requires that you make some assumptions about your customers and how they use the site.

An Internet-based application has many failure points that you should consider when designing a testing approach. The following list provides some examples of the challenges associated with testing Internet-based applications:

• Large and varied user base. The users of your website possess different skill sets, employ a variety of browsers, and use different operating systems or devices. You can also expect your customers to access your website using a wide range of connection speeds. Ten years ago not everyone had broadband Internet access. Today, most do. However, you still need to consider bandwidth as Internet content becomes “richer” and more interactive.
• Business environment. If you operate an e-commerce site, then you must consider issues such as calculating taxes, determining shipping costs, completing financial transactions, and tracking customer profiles. These requirements may necessitate a number of external links to third-party servers or databases to manage these billing and shipping tasks, for example. The developer must thoroughly understand the structure of the remote system, and work closely with its owners and developers to ensure security and accuracy.
• Locales. Users may reside in other countries, in which case you will have internationalization issues such as language translation, time zone differences, and currency conversion.
• Security. Because your site is open to the world, you must protect it from hackers. They can bring your website to a grinding halt with denial-of-service (DoS) attacks, or rip off your customers' credit card information.
• Testing environments. To properly test your application, you will need to duplicate the production environment. This means you should use Web servers, application servers, and database servers that are identical to the production equipment. For the most accurate testing results, the network infrastructure will have to be duplicated as well, which includes routers, switches, and firewalls.

Even from this list, which could be expanded considerably by including viewpoints from a wide variety of developers and businesses, you can see that configuring a testing environment is one of the most challenging aspects of e-commerce development. Testing applications that process financial transactions requires the most effort and expense. You must replicate all the components, both hardware and software, used for the application to produce valid test results. Configuring such an environment is a costly endeavor. You will incur not only equipment costs, but labor costs as well. Most companies fail to factor in these expenses when creating a budget for their applications, and those that do generally underestimate the time and monetary requirements. In addition, the testing environment needs a maintenance plan to support application upgrade efforts.

Another significant testing challenge you face is testing browser compatibility. There are several different browsers on the market today, and each behaves differently. Although standards exist for browser operation, most vendors enhance their products in an effort to attract a loyal user base. Unfortunately, this causes the browsers to operate in a nonstandard way. We cover this topic in greater detail later in this chapter.

As noted, you will face many challenges when testing Internet-based applications; therefore, the best way to proceed is to narrow your testing efforts to specific areas. Table 10.1 identifies some of the most important areas to test, to help ensure that users have a positive experience on your website.

Table 10.1 Examples of Presentation, Business, and Data Tier Testing

Presentation Tier	Business Tier	Data Tier
Ensure fonts are the same across browsers.	Verify proper calculation of sales tax and shipping charges.	Ensure database operations meet performance goals.
Confirm that all links point to valid files or websites.	Ensure documented performance rates are met for response times and throughput rates.	Verify that data are stored correctly and accurately.
Verify that graphics are the correct resolution and size.	Verify that transactions complete properly.	Verify that you can recover using current backups.
Spell-check each page.	Confirm that failed transactions roll back correctly.	Test failover or redundancy operations.
Have a copy editor check grammar and style.	Ensure data are collected correctly.	Test for proper data encryption and security (credit card and user's personal information, in particular).
Check cursor positioning when page loads to ensure it is in the correct text box.		Test backend data entry and management routines for usability and accuracy.
Confirm that default button is selected when the page loads.
Check for consistent and user-friendly feedback on interactive operations.
Check for business- or industry-specific terms and style.

Because the first impression is the most important impression, some of your testing will focus on usability and human-factor concerns. This area concentrates on the look and feel of your application. Items such as fonts, colors, and graphics play a major role in whether users accept or reject your application. Keep in mind, the developer has little or no control over who will access a given application, how much computer knowledge they have, whether or not they are motivated to stay with an application in the face of navigation issues, or what users might ultimately expect in terms of information or performance.

System performance greatly influences a customer's first impression. As mentioned earlier, Internet users want instant gratification. They will not wait long for pages to load or transactions to complete. Literally, a few seconds' delay can cause a customer to try another site. Poor performance may also lead customers to doubt the reliability of your site. Therefore, you should set performance goals then design tests that reveal problems that cause your site to miss the goals.

Users also demand that their transactions complete rapidly and accurately when purchasing products or services from your site. They do not, and should not, tolerate inaccurate billings or shipping errors. Probably worse than losing a customer is finding yourself liable for more than the transaction amount if your application does not process financial transactions correctly.

Your application likely will collect data to complete tasks such as purchases or e-mail registrations. Therefore, you should ensure that the data you collect are valid. For example, make sure that phone numbers, ID numbers, currencies, e-mail addresses, and credit card numbers are the correct length and are properly formatted. In addition, verify the integrity of your data. Localization issues can easily cause data corruption via truncation due to character-set issues.

In the Internet environment, it is critical to keep the website available for customer use. This requires that you develop and implement maintenance guidelines for all the supporting applications and servers. A Web server and RDBMS require a high level of management. You must monitor logs, system resources, and backups, and respond to any anomalies immediately. As described in Chapter 6, you want to maximize the mean time between failures (MTBF) and minimize the mean time to recovery (MTTR) for these systems.

Finally, network connectivity is another area where it is important to focus your testing efforts. At some point, you can count on losing network connectivity. The source of the failure might be the Internet itself, your service provider, or your internal network. Therefore, you need to create contingency plans for your application and infrastructure so your systems respond gracefully when an outage occurs. Keeping with the theme of testing, design your tests to break your contingency plans.

Testing Strategies

Developing a testing strategy for Internet-based applications requires a solid understanding of the hardware and software components that make up the application. As is critical to successful testing of standard applications, you will need a specification document to describe the expected functionality and performance of your website. Without this document, you will not be able to design the appropriate tests.

You need to test components developed internally and those purchased from a third party. For the components developed in-house you should employ the tactics presented in earlier chapters. This includes creating unit/module tests and performing code reviews. Integrate the components into your system only after verifying that they meet the design specifications and functionality outlined in the specification document.

If you purchase components, then you need to develop a series of system tests to validate that they perform correctly, independently of your application. Do not rely on the vendor's quality-control program to detect errors in its components. Ideally, you should complete this task independently of your application testing. Integrate these components only once you have determined that they perform acceptably. Including a nonfunctional third-party component in your architecture makes it difficult to interpret test results and identify the source of errors. Generally, you will use black-box approaches for third-party components because you rarely will have access to the component internals.

Testing Internet-based applications is best tackled with a divide- and-conquer approach. Fortunately, the architecture of Internet applications allows you to identify discrete areas to target testing. Figure 10.1 presented the basic architecture of Internet applications. Figure 10.2 provides a more detailed view of each tier.

As mentioned earlier in this chapter, Internet applications are considered three-tier client-server applications. Each tier, or layer, from Figure 10.2 is defined as follows:

• Presentation layer. The layer of an Internet application that provides the user interface (UI; or GUI, graphical user interface).
• Business layer. The layer that models your business processes, such as user authentication and transactions.
• Data layer. The layer that houses data used by the application or that is collected from the end user.

Each tier has its own characteristics that encourage test segmentation. Testing each tier independently allows you to more easily identify bugs and errors before complete system testing begins. If you rely only on system testing, then you may have a difficult time locating the specific components that are creating the problem.

Table 10.2 lists items that you should test in each tier. The list is not comprehensive, but provides you with a starting point to develop your own testing criteria. In the remainder of this chapter we provide more details on how to test each tier.

Table 10.2 Items to Test in Each Tier

Test Area	Comments
Usability/human factors	Review overall look and feel. Fonts, colors, and graphics play a major role in the application aesthetics. Ensure that all user input is acknowledged so that it is clear to the user that input has been accepted.
Performance	Check for fast-loading pages. Check for quick transactions. Poor performance often creates a bad impression.
Business rules	Check for accurate representation of business process. Consider business environment for target user groups. Ensure that business or industry conventions of terminology and style are followed.
Transaction accuracy	Verify that transactions complete accurately. Confirm that cancelled transactions roll back correctly. Is input verification sufficiently strong to support security and accuracy requirements?
Data validity and integrity	Check for valid formats of phone number, e-mail addresses, and currency amounts. Ensure proper character sets.
System reliability	Test the failover capabilities of your Web, application, and database servers. Maximize MTBF and minimize MTTR.
Network architecture	Test connectivity redundancy. Test application behavior during network outages.

Presentation Layer Testing

Testing the presentation layer consists of finding errors in the GUI, or front end, of your application. This important layer serves as the “curb appeal” of your site, so detecting and correcting errors here are critical to presenting a quality, robust website. If your customers encounter errors in this layer, they may not return. They may conclude, for example, that if your company posts Web pages with misspelled words, it cannot be trusted to successfully execute a credit card transaction.

In a nutshell, presentation layer testing is very labor intensive. However, just as you can segment the testing of an Internet application into discrete entities, you can do the same when testing the presentation layer. Here are the three major areas of presentation layer testing:

Content testing involves checking the human-interface element of a website. You need to search for errors in font type, screen layout, colors, graphic resolutions, and other features that directly affect the end-user experience. In addition, you should verify the accuracy of the information on your website. Providing grammatically correct, but inaccurate, information harms your company's credibility as much as any other GUI bug. Inaccurate information may also cause legal problems for your company.

Test the website architecture by trying to find navigational and structural errors. Search for broken links, missing pages, wrong files, or anything that sends the user to the wrong area of the site. These errors can occur very easily, especially for dynamic websites and during development or upgrade phases. All a project team member needs to do is rename a file, and its hyperlink becomes invalid. Similarly, if a graphic element is renamed or moved, then a hole will exist in your Web page because the file cannot be found. You can validate your website's architecture by creating a unit test that checks each page for architectural problems. As a best practice, you should migrate architecture testing into the regression-testing process as well. Numerous tools exist that can automate the process of verifying links and checking for missing files.

White-box testing techniques are useful when testing website architecture. Just as program units have decision points and execution paths, so do Web pages. Users may click on links and buttons in any order, which will navigate to another page. For large sites, there exist many combinations of navigation events that can occur. Review Chapter 4 for more information on white-box testing and logic coverage theory.

As mentioned earlier, testing the end-user environment—also known as browser-compatibility testing— is often the most challenging aspect of testing Internet-based applications. The combination of browsers and an operating system (OS) is very large. Not only should you test each browser configuration, but different versions of the same browser as well. Vendors often improve some feature of their browsers with each release, which may or may not be compatible with older versions. It is interesting (and frustrating) to see that even in this era of advanced Internet development and functionality, you can still encounter Web pages that display a message saying the site is not compatible with the Web browser you are using. It should not be the user's responsibility to choose the right browser to access your site. To ensure a successful user visit, spend extra time in application design, development, and testing with a wide variety of browsers and operating systems.

User environment testing becomes more convoluted when your application relies heavily on client-side script processing. Every browser has a different scripting engine or virtual machine to run scripts and code on the client's computer. Pay particular attention to browser-compatibility issues if you use any of the following:

• ActiveX controls
• JavaScript
• VBScript
• Java applets
• HTML 5
• Adobe Flash
• PHP

You can overcome most of the challenges associated with browser compatibility testing by generating well-defined functional requirements. For example, during the requirements-gathering phase, your marketing department may decide that the application should be certified to work only with certain browsers. On the one hand, this requirement eliminates a significant amount of testing because you will have a well-defined target platform to test against. On the other hand, while this might be a cost- and time-saving decision, it may not be a smart business decision. The days when a single (or even a few) Web browser applications dominated the user community are long past. Good business practice would be to design and test against a wide range of possible user Web browser applications.

Business Layer Testing

Business layer testing focuses on finding errors in the business logic of your Internet application. You will find testing this layer very similar to that of stand-alone applications, in that you can employ both white- and black-box techniques. You will want to create test plans and procedures that detect errors in the application's performance specification, data acquisition, and transaction processing.

You should employ white-box approaches for components developed in-house, because you have access to the program logic. For third-party components, however, black-box testing techniques should comprise your primary testing approach. You will start by developing test drivers to unit-test the individual components. Next, you can perform a system test to determine whether all the components work together correctly.

When conducting a system test for this layer, you need to mimic the steps a user performs when purchasing a product or service. For example, for an e-commerce site you may need to build a test driver that searches inventory, fills a shopping cart, and checks out. Pragmatically modeling these steps can prove challenging.

The technologies that you use to build the business logic dictate how you build and conduct your tests. There are numerous technologies and techniques you may use to build this layer, which makes it impossible to suggest a cookie-cutter testing method. For instance, you might architect your solution using a dedicated application server such as JBoss. Or you could have stand-alone CGI modules written in C, Python, or Perl.

Regardless of your approach, there exist certain characteristics of your application that you should always test. These areas include the following:

• Performance. Test to see whether the application meets documented performance specifications (generally specified in response times and throughput rates).
• Data validity. Test to detect errors in data collected from customers.
• Transactions. Test to uncover errors in transaction processing, which may include credit card processing, e-mailing verifications, and calculating sales tax.

Performance Testing

A poorly performing Internet application raises doubt in your user's mind about its robustness, and often turns the person away. Lengthy page loads and slow transactions are typical examples. To help achieve adequate performance levels, you need to ensure that operational specifications are written during the requirements-gathering phase. Without written specifications or goals, you cannot know whether your application performs acceptably. Operational specifications are often stated in terms of response times or throughput rates. For instance, a page should load in x seconds, or the application server will complete y credit card transactions per minute.

A common approach you may use when evaluating performance is stress testing. Often, performance degrades to the point of being unusable when the system becomes overloaded with requests. This might cause time-sensitive transactional components to fail. If you perform financial transactions, then component failures could cause you or your customer to lose money. The concepts on stress testing presented in Chapter 6 apply to testing business layer performance.

As a quick review, stress testing involves blasting the application with multiple logins, and simulating transactions to the point of failure so you can determine whether your application meets its performance objectives. Of course, you need to model a typical user visit for valid results. Just loading the homepage does not equate to the overhead of filling a shopping cart and processing a transaction. You must fully tax the system to uncover processing errors.

Stress-testing the application also allows you to investigate the robustness and scalability of your network infrastructure. You may think that your application has bottlenecks that allow only x transactions per second. But further investigation shows that a misconfigured router, server, or firewall is throttling bandwidth. Therefore, you should ensure that your supporting infrastructure components are in order before beginning stress testing. Not doing so may lead to erroneous results.

Data Validation

An important function of the business layer is to ensure that data collected from users are valid. If your system operates with invalid information, such as erroneous credit card numbers or malformed addresses, then egregious errors may occur. If you are unlucky, the errors could have financial implications for you and your customers. You should test for data collection errors much like you search for user-input or parameter errors when testing stand-alone applications. Refer to Chapter 5 for more information on designing tests of this nature.

Transactional Testing

Your e-commerce site must process transactions correctly 100 percent of the time. No exceptions. Customers will not tolerate failed transactions. Besides a tarnished reputation and lost customers, you may also incur legal liabilities associated with failed transactions.

You can consider transactional testing as system testing of the business layer. In other words, you test the business layer from start to finish, trying to uncover errors. Once again, you should have a document specifying exactly what constitutes a transaction. Does it include a user searching a site and filling a shopping cart, or does it consist only of processing the purchase?

For a typical Internet application, the transaction component is more than completing a financial transaction (such as processing credit cards). Typical events related to customer transactions include:

• Searching inventory.
• Collecting items the user wants to purchase.
• Presenting the user with related items that might be of interest.
• Presenting users with product or company reviews from other users.
• Soliciting and capturing product or company reviews from the current user.
• Creating or accessing a user account.
• Purchasing items, which may involve calculating sales tax and shipping costs, as well as processing financial transactions.
• Notifying the user of the completed transaction, usually via e-mail.

In addition to testing internal transaction processes, you must test the external services, such as credit card validation, banking, and address verification. You typically will use third-party components and well-defined interfaces to communicate with financial institutions when conducting financial transactions. Don't assume these items work correctly. You must test and validate that you can communicate with the external services and that you receive correct data back from them.

Data Layer Testing

Once your site is up and running, the data you collect become very valuable. Credit card numbers, payment information, and user profiles are examples of the types of data you may collect while running your e-commerce site. Losing this information could prove disastrous and crippling to your business. Therefore, you should develop a set of procedures to protect your data storage systems.

Testing the data layer consists primarily of testing the database management system that your application uses to store and retrieve information. Smaller sites may store data in text files or open-source databases. Larger, more complex sites, use full-featured enterprise-level databases. Depending upon your needs, you may use both approaches.

One of the biggest challenges associated with testing this layer is duplicating the production environment. You must use equivalent hardware platforms and software versions to conduct valid tests. In addition, once you obtain the resources, both financial and labor, you must develop a methodology for keeping production and test environments synchronized.

As with the other tiers, you should search for errors in certain areas when testing the data layer. These include the following:

• Response time. Quantifying completion times for Structured Query Language (SQL) operations.
• Data integrity. Verifying that the data are stored correctly and accurately.
• Fault tolerance and recoverability. Maximizing the MTBF and minimizing the MTTR.

Response Time Testing

Slow e-commerce applications cause unhappy and untrusting customers. Thus, it is in your interest to ensure that your website responds in a timely manner to user requests and actions. Response time testing in this layer does not include timing page loads; rather, it focuses on identifying database operations that do not meet performance objectives. When testing the data-tier response time, you want to ensure that individual database operations occur quickly so as not to bottleneck other operations.

That said, before you can measure database operations, you must understand what constitutes one. For this discussion, a database operation involves inserting, deleting, updating, or querying data from the RDBMS. Measuring the response time simply consists of determining how long each operation takes. You are not interested in measuring transactional times, as that may involve multiple database operations. Profiling transaction speeds occurs while testing the business layer.

Because you want to isolate problem database operations, you do not want to measure the speed of a complete transaction when testing data layer response times. Too many factors may skew the test results if you test the whole transaction. For example, if it takes a long time for users to retrieve their profiles, you need to determine where the bottleneck for that operation resides. Is it the SQL statement, Web server, or firewall? Testing the database operation independently allows you to identify the problem. In this example, if the SQL statement is poorly written, it will reveal itself when you test response time.

Data layer response-time testing is plagued with challenges. You must have a test environment that matches what you use in production; otherwise, you may get invalid test results. Also, you must have a thorough understanding of your database system to make certain that it is set up correctly and operating efficiently. You may find that a database operation is performing poorly because the RDBMS is configured incorrectly.

Generally speaking, though, you perform most response-time testing using black-box methods. All you are interested in is the elapsed time for database transactions. Many tools exist to help with these efforts, or you may write your own.

Data Integrity Testing

Data integrity testing is the process of finding inaccurate data in your data stores. This test differs from data validation, which you conduct while testing the business layer. Data validation testing tries to find errors in data collection. Data integrity testing strives to find errors in how you store data.

Many factors can affect how the database stores data. The datatype and length can cause data truncation or loss of precision. For date and time fields, time zone issues come into play. For instance, do you store time based on the location of the client, the Web server, the application server, or the RDBMS? Internationalization and character sets can also affect data integrity. For example, multibyte character sets can double the amount of storage required, plus they can cause queries to return padded data.

You should also investigate the accuracy of the reference tables used by your application, such as sales tax, zip codes, and time zone information. Not only must you ensure that this information is accurate, you must keep it up to date.

Fault Tolerance and Recoverability Testing

If your e-commerce site relies on an RDBMS, then the system must stay up and running. There is very little, if any, downtime availability in this scenario. Thus, you must test the fault tolerance and recoverability of your database system.

One goal of database operations, in general, is to maximize MTBF and minimize MTTR. You should find these values specified in the system requirements documentation for your e-commerce site. Your goal when testing the database system robustness is to try to exceed these numbers.

Maximizing MTBF depends on the fault-tolerance level of your database system. You might have a failover architecture that allows active transactions to switch to a new database when the primary system fails. In this case, your customers might experience a short service disruption, but the system should remain usable. Another scenario is that you build fault tolerance into your application so that a downed database affects the system very little. The types of tests you run depend on the architecture.

You should consider database recovery as equally important. The objective of recoverability testing is to create a scenario in which you cannot recover that database. At some point, your database will crash, so you need to have procedures in place to recover it very quickly. The planning for recovery begins in obtaining valid backups. If you cannot recover the database during recoverability testing, then you need to modify your backup plan. A fault-tolerant database system may reside in multiple locations connected over a private or shared network. This aspect of database management must be tested as well. If the local server fails, are the remote systems current, and can your software connect to a remote system quickly? What happens if one or more network connections fail? What happens if a system failure occurs while data is being written?

In general, strive to test all aspects of the system, everything required to support all levels of activity and data integrity for which your application is designed.

Summary

The public Internet did not exist when the first edition of this book was written. Indeed, remotely accessed systems, and applications in general, were infantile compared to those of today's Internet. Users in those early days mostly were sophisticated, computer-savvy folk who could tolerate a fairly high level of difficulty in accessing and using remote applications. Today, Internet users may know very little about the actual operation of computers and computer software, yet they have a virtually infinite choice of commercial sites from which to choose. Consequently, they have little or no patience for a Web-based application that is unattractive, difficult to use, or dysfunctional. Therefore, in-depth testing of any Internet application is extremely important.

Testing software in the Internet environment presents many challenges, particularly the large and varied user base and the need for extreme accuracy and security for electronic commerce applications. In general, we want to test three main Internet application areas: presentation (or user interface), business logic, and data management. As might be expected, large user-base applications require extensive user testing (see Chapter 7 for more information on this process) to ensure that the software meets design specifications and user acceptance criteria. It is important for any software application to be attractive and easy to use, but applications for the Internet are judged more harshly. In this environment, software success often equates to business success, and this factor alone should drive developers toward aggressive and thorough testing.