Testing Strategy for Internet Applications Essay Example

style="text-align: justify;">Service

• Performance and stress Testing
• Reliability/failover testing
• Service management testing

Usability

• Collaborative usability
• Inspection
• Usability testing
• Web accessibility checking

Security

• Security assessment
• Penetration testin
• Large-scale integration
• Systems integration testing
• Business integration testing

Test types for Static/Dynamic, Automatic/Manual

Test types can be static or dynamic and also can be automatic or manually. For example, static tests are those relating to inspection, review, or automated static analysis of development deliverables.

The test types do not always fit into the traditional unit, integration, system, and acceptance test stages. So, a structure that has test stages that categorize the test types in a technical way:

• Desktop development testing (broadly, of software that executes under the control of the browser);
• Infrastructure testing (of what runs on the servers);
• System testing (of the complete system in isolation);
• Large-scale integration (with other systems and business processed);
• Postdeployment monitoring (of live sites, retaining automated tests and using external services)

 Static Testing

Static tests are those that do not involve executing software under test by inputting data and commands and comparing the software behavior with expected results. Static tests do involve inspections and reviews of project documentation, specifications, or code. Static analysis of code using automated tools also counts as a static test and is an effective way of detecting not only faults, but also poor programming practices lists the static testing addresses.

Web Page Integration testing

The listed in

Table 7.3 all relate to failures to that would be noticeable as soon as a user first navigates to a page, clicks in a link on button to navigate to another page, or invokes a server-based components. These faults are grouped together because they relate to the integration of HTML pages to embedded objects, linked pages, or server-based functionality. Collecting these faults together means that the testing required to address them can be performed on a single web pages component when the linked objects are available. As each component is developed and combined with its linked components the links to other pages and objects can be checked within a development environment. Essentially, this is an integration process, and the tests that accompany it are integration tests. One of the biggest benefits of these tests is that they can largely be automated.

 Functional Testing

Functional tests demonstrate that software meets its functional requirements, which describe what the system must do. Nonfunctional requirements, by and large, describe how the system must deliver its functionality. (Is it fast? Is it usable? Is it secure?) Performance, usability, and security testing are therefore nonfunctional test types. Configuration testing could also be regarded as a nonfunctional test, but for most practical purposes, configuration testing is dominated by functional regression tests using a variety of platforms and configurations.

Architecture and Components

Before we look at the test types themselves in more detail, it is worth spending a little time looking at how Web applications are normally built from components. The problem with architectures and components is that there are an almost infinite number of combinations and permutations of

these architectures, and the technical detail required to understand and test all such components would be overwhelming. At that moment, we'll focus specially on the common browser-based functionality and the components residing on Web servers that are the next layer in these architectures.

 Test types and the objects under test

Figure 7.4 presents a schematic of a typical architecture for a Web system. As with many larger, more complex Web sites, its four-tiered architecture comprises the following:

• First tier: client browser;
• Second tier: Web server(s) accessed through the Internet;
• Third tier: application or object server(s);
• Fourth tier:
• Database server;
• Other legacy systems;
• External interfaces (e.g., banks).

The diagram sets out the boundaries for four test types, each of which indicates the system components that are within scope. In the real world, systems can be much larger and more complex, but they can also be smaller and simpler. Table 7.5 presents somewhat idealized descriptions of the test types described here and their scopes in order to put them into context. The scope of the test stages and the test types they include much less ordered and clear-cut.

 Automated Test Execution

The test types dealing with functionality can all benefit from the use of automated test execution tools. In the server-based component testing section, we suggest that custom-built dummy HTML forms or test drivers can support this test activity, and these are described briefly.

It remains a sad fact that most test-running tools end up on the shelf. The promise of test automation is very high, but

the achievement of this promise can be quite a challenge. At this point, we will say that test automation should be considered as early as test planning is undertaken.

 Browser Page Testing

Browser page tests cover the objects that execute within the browser, but do not exercise the server-based components. These components typically include the following:

• JavaScript (or VBScript) code embedded within an HTML page that implements special effects, or field validation;
• Java applets that implement screen functionality or graphical output;
• ActiveX components that execute within the context of a Web page;
• Plug-ins such as Quicktime or RealPlayer.

 Server-Based Component Testing

Server-based component testing covers the objects that execute on the server, but are initiated by Java applets, ActiveX components, or HTML forms-based user interactions on the browser. These components typically perform standard processes, such as the following:

• Security checking and validation;
• Business logic to perform database enquiries or updates;
• Product catalog searches;
• Order processing;
• Credit checking and payment processing.

Usually, the server-based forms handlers are written at the same time as the forms that invoke them; however, we have found two problems with testing server-based code using the user interface:

• In some projects, the user interface may actually be the last thing written, so server-based components cannot be tested completely until very late in the project.
• It is common for server-based components to be programmed to deal with a very broad range of input parameters, invoking complex transactions that interface with legacy systems. Large numbers of tests
  

may be difficult to implement manually, so an automated alternative can be more effective and economic.

Transaction Link Testing

Transaction link testing (link testing) aims to address the problem of integrating the complete end-to-end functionality to ensure that the entire transaction is processed correctly from the user action on the browser interface to the back-end systems. Link testing focuses very much on selected test cases that exercise particular interfaces between components in the technical architecture to ensure that mismatches between components are minimized.

Application System Testing

Application system testing aims to cover functional testing of the application as a whole. Where a supplier providing the system is unable to build a complete test environment that includes, for example, the client's legacy systems and interfaces to banks or other partners, system testing would take place in an environment with client-supplied interfaces stubbed out. Testing of the complete technical architecture is covered later in large-scale integration testing and is likely to be a key part of acceptance testing. Application system testing in the form described here is most likely to be performed by the suppliers of the system itself in an environment that allows the system to be tested in isolation from its external interfaces.

Context Testing

There are several risks relating to the context (or, perhaps more correctly the loss of context) of Web transactions. One of the differences between client/ server and Web applications is that for home-based users, the network connection is under the user's control. Dial-up connections are usually temporary and are generally less reliable than the permanent high-speed LAN connections most office-based workers use. Connection, disconnection,

reconnection anomalies cause serious disruption to most users when they access the Web. The behavior of Web sites under these scenarios varies widely across Web sites, and in many cases, poor design causes Web site owners and their users dismay.

Unlike with client/server applications, the user accesses a Web application through a browser. The browser itself has buttons and controls that allow the user to interfere with the normal operation of the Web site in the following ways:

• The back button allows the user to go back to a previously displayed Web page cached in the browser's memory. If that page is used to execute a purchase with a one-time discount, the transaction could be re-executed many times with the discount applied. To avoid this, the developer can make these pages expire immediately so that the browser cannot just restore them from its cache.
• Refresh (IE) and reload (Netscape) buttons allow users to re-execute transactions that produce the current Web page. Again, this could allow users to repeat a system transaction without having to repeat previous pages.
• The history facilities in browsers bookmark previously visited pages and navigate directly back to them, which re-executes the transaction that loaded the page. The application Web pages could therefore, in principle, be re-executed in any order the user wished, which could wreak havoc with the application.

Localization Testing

Multilingual sites are often built with all language-specific material codified into a database. In this case, localization testing is all about verifying that all user messages, prompts, and output are translated correctly and that the functionality delivered to the end user

is identical. Checking translations isn't quite as simple as comparing text translation with a foreign dictionary. Have you ever seen the names of dishes on a foreign restaurant's menu translated literally? The people checking translations should speak the target language as their mother tongue so you can be sure that the translations are accurate, not just literal.

Configuration Testing

Configuration testing aims to demonstrate that your Web application will operate correctly on your nominated range of client hardware, OS, and browser combinations. On the Internet, you have no control over the end users' platform, so to avoid problems later, it is best to test a range of configurations to ensure that you can support at least the most common combination. The problem, of course, is that there is a virtually unlimited number of possible combination, Table 7.6 provide, some indication of the possibilities that face the tester.

Most of the component types listed in Table 7.6 have multiple versions. The number of combinations and permutations are in the hundreds, or even thousands. The essential difficulty of configuration testing is therefore deciding on the scope of the testing. The big questions include the following:

• What do your users actually use?
• Which configurations should you support? (Not all will be worth considering)
• Which can you test economically?
• Which can you test automatically?

Service Testing

Companies build e-business Web sites to provide a service to customers. In many cases, these sites also have to make money. If a Web site provides poor service, customers will stop using it and find an alternative. Quality of service

as provided by a Web site could be defined to include such attributes as functionality, performance, reliability, usability, security, and so on. For our purposes, however, we are separating out three particular Web service objectives that come under the scrutiny of what we will call "Service Testing":

• Performance: The Web site must be responsive to users while supporting the loads imposed upon it.
• Reliability: The Web site must be reliable or continue to provide a service even when a failure occurs if it is designed to be resilient to failure.
• Manageability: The Web site must be capable of being managed, configured, and changed without a degradation of service notice able to end users.

What Is Performance Testing?

Performance testing normally requires a team of people to help the testers. These are the technical architects, server administrators, network administrators, developers, and database designers and administrators. These technical experts are qualified to analyze the statistics generated by the resource monitoring tools and judge how best to adjust the application or to tune or upgrade the system. If you are the tester, unless you are a particular expert in these fields yourself, don't be tempted to pretend that you can interpret these statistics and make tuning and optimization decisions. It is essential to involve these experts early in the project to get their advice and commitment and, later, during testing, to ensure that bottlenecks are identified and resolved.

 Reliability/Failover Testing

Assuring the continuous availability of a Web service may be a key objective of your project. Reliability testing helps to flush out obscure faults that cause unexpected failures

so they can be fixed. Failover testing helps to ensure that the measures designed for anticipated failures actually work.

Service Management Testing

When the Web site is deployed in production, it has to be managed. Keeping a site up and running requires that it be monitored, upgraded, backed up, and fixed quickly when things go wrong. The procedures that Web site managers use to perform upgrades, backups, releases, and restorations from failures are critical to providing a reliable service, so they need testing, particularly if the site will undergo rapid change after deployment.

The management procedures fall into five broad categories:

• System shutdown and start-up procedures;
• Server, network, and software infrastructure and application code installation and upgrades;
• Server, network, and software infrastructure configuration and security changes;
• Normal system backups;
• System restoration (from various modes of failure) procedures;

The first four procedures are the routine, day-to-day procedures. The last one, system restoration, is less common and is very much the exception, as they deal with failures in the technical environment where more or less infrastructure may be out of service.

Usability Assessment

Put an unusable site onto the Web, and your users will not stick around very long. Your users have the freedom to abandon your site and visit your competitors'. It may have been possible to implement difficult-to-use systems in the past, but it is no longer. One of the key selling points for Web sites is their ease of use. A usability fault is a potential problem in the appearance or organization of a system that makes it

less easy for users to use. Operationally, a usability fault is any clear or evident violation of an established usability principle or guideline; or it is any aspect of a system that is likely to lead to confusion, error, delay, or failure to complete some task on the part of the user.

Usability faults have two dimensions:

• The location and identity of a fault;
• The problem and rationale for identifying it.

Usability and usability assessment have never been as important as they are now. Typical Web site users have low boredom, frustration, inconvenience, and insecurity thresholds. Home-based users may never have been trained in the use of a computer, let alone browsers and your Web applications. Regardless of the user's level of sophistication, if your Web application doesn't allow enquiries to be made and orders to be placed easily, quickly, and reliably, the site will fail. If the user cannot easily understand from your Web site how to proceed, the user will leave your site and go elsewhere.

Collaborative Usability Inspection

Collaborative usability inspection is a systematic examination of a finished product, design, or prototype from the point of view of its usability by intended end users. The process is a team effort that includes developers, end users, application or domain experts, and usability specialists working in collaboration. A major benefit of the method is its own usability: It is easy to learn. Experienced inspection teams have been known to detect 100 usability faults per hour. The collaborative nature of these inspections means that users and developers understand the relationship between user interactions and design constraints and

decisions. These inspections can be performed at any stage of development from the assessment of prototypes to the finished Web site, but, of course, the cost of fault correction increases the later the inspections take place.

Heuristics on Which to Base Inspections

Inspections are guided by a set of rules or heuristics for good user-interface design. These are used as a framework for identifying and categorizing usability faults.

Nielsen promotes a (popular) set of 10 Web design heuristics summarized in His book, Designing Web Usability, is packed with usability design guidelines from which you can extract your own preferred rules if you care to.

Usability Testing

Usability testing aims to detect usability faults in a system by using the system to perform selected tasks. There are two broad ways of performing usability testing: in a usability laboratory or in the field. We will only consider field usability testing here.

Usability testing of a finished system is effective for finding certain faults, but is no substitute for good usability design. Experience shows that usability tests uncover fewer faults than inspections, but the faults that are found are often more subtle or unusual in nature, and they can be more serious. Usability testing requires that a working system be available, so these tests tend to be possible only late in the project. If there isn't time to fix these faults, they may be left in the released product. Overall, usability tests are most effective when used to investigate specific areas of an application or to explore particular issues.

 Web Accessibility Checking

It is possible to conduct manual inspections of

a system to detect departures from user-interface standards or accessibility guidelines. In the context of the Web, accessibility refers to the ease with which anyone can make use of the Web, regardless of his or her technology, location, or disability. The most important accessibility guidelines for Web-based systems are defined as part of the Web Accessibility Initiative (WAI) - the "Web Content Accessibility Guidelines". This document defines a comprehensive collection of guidelines to make your Web pages more accessible to users with disabilities, although the vast majority of guidelines would make a site more accessible (or usable) to all users.

There are several assistive technologies now available to help users with disabilities use the Web. These include the following:

• Text-to-speech (TTS) browsers that use synthesized speech to read text on Web sites to a user;
• Text-only browsers that render Web sites in a text-only format;
• Voice-enabled browsers that navigate Web sites using speech commands;
• Specialized keyboards and mice;
• Voice-recognition software;
• Refreshable braille devices that transfer text onto a special device;
• Screen magnification or enhancement software.

Security Testing

When most people think of security (and the challenge that hackers present to it), they have a vision of longhaired college dropouts working into the wee hours at a furious pace, trying to crack a remote system. By guessing passwords and through perseverance, luck, and ingenuity, they break into the bank, government department, or evil mastermind's mainframe system. Although this image works well for the movies, it isn't helpful to our understanding of the security threats that face e-business systems. Determined

attackers often work in teams, they work almost entirely with automated tools, and they may wait patiently for months before attacking perhaps hundreds of sites in a single day. Many of them adopt a scattergun approach to acquiring targets, but they really are more sophisticated than the movies usually represent them.

Although outsiders are a serious threat, it should be borne in mind that insiders perform many break-ins. Whatever their motives (frustration, anger, or a grudge against an employer), insiders are particularly dangerous. If they are still employed, not only do they have access to your systems, they probably also know your network topology and the servers that host critical services and are trusted within your organization - what they don't know, they can find our easily. Even if they have left your company, their knowledge gives them a head start in their intrusion efforts. Either way, your internal security policies should be regularly reviewed and thoroughly implemented.

Security Assessment

A security assessment is a review of a site's hardware and software configuration to identify security vulnerabilities. The assessment team works with the full cooperation of the technical staff that designed, implemented, and supported the site to be assessed. Security assessments, being systematic attempts to identify all security weak points, are the most cost-effective way to address security concerns. The structure and definition of an assessment varies with the scale of the project and objectives of the organization that commission it. Assessments can be conducted from an internal or external point of view.

Assessments can focus on servers, networks, or firewalls and can be technically or non technically oriented.

 Penetration

Testing

Penetration tests aim to demonstrate that within a short period an intrusion can be achieved and that a system is vulnerable to attack. Most attempted Internet attacks are performed by uninventive script kiddies. There are a wide range of capabilities between script kiddies (who know little) and determined attackers who have in-depth networking experience and programming knowledge. Somewhere in between, there are the casual hackers. These are probably the main threat to Web sites. Typically, a determined attacker will spend up to 3 days trying to crack a site, so penetration testers are usually given approximately 3 days to achieve an exploit. If the test does not expose a vulnerability, one can reasonably assume the site is secure from this kind of attacker (assuming your testers are as competent as the attacker, of course).

Large-Scale Integration Testing

The risks associated with Large-Scale Integration are the same as those we tackled using transaction link testing, but the interfaces we are concerned with here exist at a higher level between multiple systems and between systems and the business process. Integration is an often misunderstood concept because the integration process starts almost as soon as coding begins.

In an e-commerce application the scope of LSI testing might cover integration with external banks or credit-card processing systems, product wholesalers or distributors, as well as internal legacy systems.

The notion of fit is appropriate for component-to-component integration, system-to-system integration and system(s)-to-business-process integration. We have conducted business integration testing (BIT) on many client projects where user acceptance was (at least partially) based on the results of these tests. Using the same integration framework for user

acceptance makes test planning easier, and business management will support this activity because they can understand how it will give them confidence that the delivered service will work.

We are not suggesting that BIT is the same as user acceptance testing. Rather, we expect that in many organizations, the final stages of LSI testing provide some confidence to users that the system will work as they require. If you are asked to plan an acceptance test for your users, we expect that the techniques we describe in BIT in particular will play some part in your planning.

We separate LSI testing into two stages because the risks and test objectives differ. Systems integration testing (SIT) is more technically oriented because it is at this point that the physical connections between systems are established and used for the first time. The tests are somewhat more white-box-oriented in that the physical interfaces between systems must be understood enough to allow test designers to prepare tests that cover them. BIT is more focused on the paths through business processes to ensure that the integrated systems provide seamless support to the user activity throughout.

 Integration Analysis

In complex environments where a large number of interfaces are to be tested, a systematic approach to the identification of interfaces and the transactions that exercise them was essential. Because the integration knowledge is extracted from many sources, it is a good idea to get your integration inventories reviewed by the development project teams. There are three techniques for documenting integration knowledge:

• Identification of systems and system-to-system interfaces and the compilation of integration inventories;
• Identification
  

and documentation of high-level business transactions that are dependent on these interfaces or trigger their execution;

Planning and preparing an LSI test that addresses the risks of concern normally require information from all three dimensions: interfaces, transactions, and reconciliations. The integration analysis takes two views of systems and interfaces:

• A technical or system view (to prepare for SIT).
• A business view (to prepare for BIT).

The system view and the business view are similar in approach: The system view captures interfaces and transactions in terms of physical connections (files or messages) and system transactions; the business view captures interfaces in terms of business entities being transferred between applications via business transactions.

SIT

To plan SIT, the tester needs to know quite a lot about the physical interfaces between systems. Only by knowing the following about the internals can the tester design tests that will exercise these interfaces adequately:

• The details of the internals of the interface;
• The nature of the system-to-system dialogs;
• How to exercise the interface from the application user interface or batch processes;
• How to create test data to exercise the interface;
• How to find evidence that the interface works.

We said earlier that one of the problems of LSI testing is that it can be difficult to find details of interfaces. It's not just the interface details that cause problems. It may be that there is no documentation available at all for the

legacy systems. Once the integration inventories are prepared, the tester follows a simple process to define the integration test:

• For each interface, identify the dialogs between systems and which business or system events trigger them to work.
• Derive test cases for success and failure to negotiate each step in the dialog.
• Derive test cases from the interface data validation and use descriptions to ensure that valid data is transmitted, invalid data is rejected, and the storage and use of data in each interfacing system reconcile.
• Define your test environment and infrastructure needs early, so they are met in good time.

Integration tests tend to fall into one of two types: They are either very simple (and easily automated) or they are very complicated and have to be executed manually. When the tests are executed, early tests focus on the correctness of the interface calls. Later tests (usually automated) focus on memory leaks, loss of synchronization between systems, and failure and recovery of clients, servers, or the network.

 BIT

The primary aim of BIT is to provide final confirmation that systems, processes, and people work as an integrated whole to meet an organization's objectives and provide a sophisticated, efficient service to its customers. BIT takes a process- and people-oriented view of the entire system.

BIT objectives can span a large range of issues. Perhaps a new process needs to have rough edges removed; perhaps an existing process needs changing to reflect a new way of doing business. Alternatively, the training provided to end users might be the problem: perhaps users need more detailed instruction

in how to use particular aspects of the system. BIT is a more rounded approach to finding faults in system implementations, not just the software.

BIT differs from SIT in that it is more likely to be associated with user acceptance. Assuming that the technical testers have demonstrated that the interfaces between the new system and other systems work in SIT, the imperative for a business wishing to deploy the new system is to ensure the system supports the intended business activity. For example, if a system supports the on-line purchase and delivery of books, the following questions must be addressed:

• Can a customer search for a book, add it to a shopping basket, and place an order?
• Can a customer's credit card be validated and can payment be authorized and processed successfully?
• Does the legacy order processing system receive the on-line order accurately?
• Is the book in stock, located in the warehouse, packed, labeled, and dispatched correctly?
• Are order confirmation, progress notification, and thank-you e-mail messages sent at the right time? Do they reliably reach the Customer?
• Are payments processed promptly, accurately, and reliably?

Ultimately, the sponsors of the system want to know whether the new system meets the cardinal business objectives of the project. Testers must develop and execute selected business scenarios that will exercise the integrated systems to provide evidence that they support the business process in its entirety.

Compared with SIT testing, BIT may take a smaller number of test cases to give confidence that the system works correctly because the number of tests should be

limited to a finite number of business scenarios. However, BIT alone may not provide enough information on which to base acceptance of a system. Users will certainly want to see many more system transactions executed to ensure that the core functionality of the new Web system works.

Content analysis

The actual content provided by a site also needs to be "tested."

Offensive, misleading, and litigious content. An e-commerce site's contents must be sound. In the UK, legislation such as the Trade Marks Action (1994), Control of Misleading Advertisements Regulations (1988), and Obscene Publications Act (1976) applies to all published material, including Web content. Products or services that are incorrectly described or misleading (check those product descriptions!) may violate the Trade Description Act.

Infringements. Test your Web site content for infringements. Graphics and images used in the design should be royalty free (if not wholly owned); also check for copyright infringement. In some circumstances, the courts will consider use of trademarked material without the owner's written consent as infringement. Courts would almost certainly view discrediting or denigrating a competitor's brand as an infringement.

Personalization. Increasingly, e-commerce systems are incorporating customer relationship management functionality that provides personalization for individual customers. In many cases, a personalization profile determines what content the site offers to these customers. However, situations can occur where the site offers incorrect or inappropriate content to customers because of errors in the personalization functionality.

Availability

Unavailability equals lost revenue; it also harms a business's reputation and can encourage customers to take their business to competitors. Businesses need to offer 24/7 availability to their customers, with availability levels of

99 percent or higher being the desired norm.

Unacceptable levels of unavailability. Several factors can influence availability, such as hardware reliability, software reliability, the effectiveness of load balancing, and the database's ability to handle concurrent users. Before going live, predicted business usage patterns should indicate maximum stress levels. You should test system availability against the maximum stress levels plus a safety margin for a defined period of time.

Denial of service. Yahoo, Amazon.com, and Buy.com have all recently suffered denial-of-service attacks. Such attacks (also known as saturation attacks) involve bombarding the Web server with bogus requests, making it inaccessible to genuine users. Organizations are not defenseless against such attacks; Amazon.com for example, uses security software to filter out bogus requests. Test your e-commerce systems for vulnerability to denial-of-service attacks.

Backup and recovery

You can't guarantee that any component of your e-commerce system won't fail, whether hardware or software, so it's sensible to test that you can quickly recover from a failure when it does happen.

Failure/fall-over recovery. Design systems so that one component's failure doesn't necessarily bring down other components. In MS Internet Information Server (version 4.0), for example, Active Server Page scripts can run from the Web server as separate processes.

Test both the speed and ease at which systems can recover from component failure; for example, how do you restart the service? Is it a case of pressing the restart button, or should the system support team look at other factors first? Is it a simple administrative task, or one that requires specialist knowledge? For non-fatal failures, you might be able to reload the system's affected components

rather than taking the system down completely. For example, in a Java implementation, you can reload Java servlets dynamically.

Backup failure. How quick and easy it is to perform and restore backups? If database records become corrupted, for example, how quickly can you backup the data? How quickly can new hardware, software, and networking components replace failed components?

Fault tolerance. In fault-tolerant architectures, redundant hardware and software components take over when components fail. For example, if one Web server goes down, a second Web server can service requests, and the problem remains transparent to the user. Test fault tolerance by switching off individual components or simulating their failure. My colleagues and I know of one incident where the system used clustering technology to provide fault tolerance. However, testing found that the clustering technology was ineffective because it was incorrectly configured.

 Internationalization

E-commerce systems, especially B2C systems, are often required to operate across geographic boundaries. Although English is the dominant language, non-English sites are increasingly common and gaining a head start in cornering foreign markets. A system must operate in selected target countries as well as it does in its home country.

Language support. Does the site offer the option to view non-English pages? If the choice of language is based on browser preferences, does it work on all the desired browsers? Many older browsers do not support language customization.

Language display. Test that words are correctly displayed and that sentences are grammatically correct. Use a native speaker to verify that this is the case.

Cultural sensitivity. Does the site respect cultural differences between the home and foreign country?

Check that a site does not include content that is likely to offend the culture or religious affiliation of the country concerned.

Regional accounting. Developing e-commerce systems where trade takes place across accounting regions raises issues about how to charge customers. For example, tests should ensure that the system correctly calculates taxes and exchange rates for the regions concerned.

 Transactions

Transaction processing is a central element of most e-commerce systems. With distributed systems, transaction processing can span several individual systems, leading to more complex testing.

Transaction integrity. Does the system correctly perform all aspects of transaction processing? For example, does the system call the appropriate database triggers and procedures? Does it commit and roll back transactions correctly? Have system developers set the appropriate isolation levels? Devise a set of inputs that will attempt to create "nonstandard" transactions-for example, transactions with a zero quantity or value-as well as standard ones.

Throughput. The most popular Internet sites easily exceed a million hits per day. In a transactional e-commerce system, you must test the transaction engine's throughput; that is, its ability to manage, say, 1,000 transactions per minute. Most modern testing and monitoring tools have facilities for throughput testing.

Auditing. An audit trail records all transactions made by the system. Tests should verify that the audits satisfy all legal obligations, and that the auditing software captures all the required transaction details, such as transaction time and date, originator and recipient, values, and so on.

Automated Web Testing Tools

Functional/Regression testing tool (also is a Test Case and Test Script Development Tool)

Functional/Regression Testing: WinRunner

Test Automation for the

Enterprise

WinRunner is an integrated, functional testing product for enterprise and internet application. It captures, verifies and replays user interactions automatically, so that you can identify defects and ensure that business processes, which span across multiple applications and databases, work flawlessly the first time and remain reliable.

With WinRunner, organizations gain several advantages, including:

• Reduced testing time by automating repetitive tasks.
• Optimized testing efforts by covering diverse environments with a single testing tool.
• Maximized return on investment by modifying and reusing test scripts as the application evolves.

Testing with WinRunner includes three main stages:

Creating Tests: You can create tests using both recording and programming. While recording tests, you insert checkpoints where you want to check the behavior of the application being tested.

Running Tests: When you run a test, WinRunner emulates a user by entering mouse and keyboard input into your application. Each time WinRunner encounters a checkpoint in the test, it compares the current response of your application to its expected response.

Analyzing Test Results: When a test run ends, you examine the test results. WinRunner lists all the major events that occurred during the run, such as checkpoints, errors, or messages.

WinRunner Process Diagram WinRunner emulates and captures user actions into test scripts that can be used throughout the application's lifecycle, using the following process: Maintaining Tests

Building and running powerful tests are only part of the testing process. Making sure you can reuse these tests ensures that your investment in creating tests will pay off as your application evolves.

WinRunner includes several tools to help you

maintain your tests: GUI Map Editor enables you to quickly update how WinRunner recognizes objects in your application. Function Generator enables you to easily add TSL functions(test script) and user-defined functions to your tests. Debugging tools help you identify and eliminate problems in your tests.

Support for Terminal Servers

Support for Citrix and Microsoft Terminal Servers makes it possible to open several window clients and run WinRunner on each client as a single user. Also, this can be used with LoadRunner to run multiple WinRunner Vusers.

Support for More Environments

WinRunner includes support for Internet Explorer 6.x and Netscape 6.x, Windows XP and Sybase's PowerBuilder 8, in addition to 30+ environments already supported by WinRunner 7.

 Performance testing tool (Load and Stress Testing)

Load/Stress Testing: LoadRunner

The Industry Standard in Load Testing

Mercury Interactive's LoadRunner is a testing tool that predicts system behavior and performance. It can also be used to test web and e-commerce applications. It exercises your entire enterprise infrastructure by emulating thousands of users and employs performance monitors to identify and isolate problems. LoadRunner helps enterprises:

• Surface bottlenecks pre-production
• Maximize productivity of QA cycles
• Accelerate deployment

The new Tuning Module helps LoadRunner customers quickly isolate and resolve system performance bottlenecks. By adding a centralized tuning console to LoadRunner, the Tuning Module ensures that performance bottlenecks are resolved during testing, and creates optimized configuration settings that can be used in production.

The new J2EE Transaction Breakdown Module helps LoadRunner customers quickly isolate J2EE application performance bottlenecks. By tracing a transaction through the tiers of the infrastructure and

through the application, this module helps customer isolate the specific method that is causing performance problems thus reducing the time to resolution and improving the performance of the application.

GUI testing tool (also is a Test Case and Test Script Development Tool)

Load/Stress Testing: WebFT

WebFT Key Features

• Automatic Client-Side JavaScript support - All client-side JavaScript events that execute within the browser are recorded and executed during playback.
• Browser as Playback Engine - During playback, an instance of the browser displays and executes the agenda, following the exact steps recorded in the test agenda, including events performed in the client.
• "AutoRun Wizard" for Multi-agenda Execution - The AutoRun Wizard lets users set up multiple agendas to run sequentially at a specified time. Result reports can be saved to different locations, including a Web server, for example, so runtime results can be viewed online.
• Script-sharing with WebLOAD 6.0 - After verifying the functionality of your application with WebFT, you can use the same script in WebLOAD 6.0 to execute a load test. Note that some object-level test cases are not executed in WebLOAD 6.
• DOM, HTML, Browser View, and JavaScript Agenda Views - For each recorded Web page, users can view the HTML of the page, the DOM structure of the page, which is synchronized with the page's Browser View, as well as its underlying JavaScript syntax as it relates to the JavaScript agenda.
• Convert Agenda Tree to JavaScript Object - For those users who prefer to manually script their test agendas, the visual agenda tree can be converted into a
  

JavaScript Object, which can be fully edited. Single Web pages or "tree nodes" can be converted as well, keeping the visual agenda tree intact, but providing flexibility for specific custom scripting needs.

WebFT Key Benefits

• Speed implementation time - use of open standards scripting language reduces the amount of staff training required
• Reduce application development costs - through earlier detection and correction of problems and by maximizing your development resources
• Improve quality - resulting from higher quality Web applications
• Reduce test script development costs - leverage single transferable scripts for fast, easy reuse
  

of test scenarios between development teams

Usability testing tool

Visual WebTester is an easy-to-use software tool for automated functional, regression and especially usability testing of Web applications.

Visual WebTester provides the fastest, cost-effective most accurate means of conducting automated function and regression testing for Web applications. Web developers and testers can use this automated software testing tool throughout the entire application life cycle from early in development through application deployment.

Usability Testing Features

Testing made easy , No Programming knowledge necessary:

• Visual WebTester is the leading functional testing tool that lets you write comprehensive tests without programming knowledge.
• It features powerful, intuitive Visual capturing technology, an automated test case generator, sophisticated content matching
• The ability to execute data-driven tests
• You can create hundreds of functional and regression tests in less time than you would need to install other test tools.

Make Web Applications error free in an efficient way :

• The tool graphically displays extensive reports and the contents of each Web page
• test cases using an intuitive tree format
• Any errors or differences on the web pages are identified by are highlighted using an intuitive system of color-coded flags, which allows you to identify problems quickly and focus on implementing solutions.

Visual automatic test case generation :

Test the entire application and generate test cases in minutes with reusable, object-oriented Scripts that automatically capture and test all Document Object Model elements (e.g., anchors, elements,

forms, frames, XML, images, image maps, links, etc) using the simple visual recording and playback mechanism. Also combine scripts to generate complex test cases.

Data source wizard :

• Creates data-driven tests without programming.
• A single test script can be used repeatedly with varying input and response data using values from an external data source like an RDBMS.

Security testing tool

Security Testing: AppScan 4.0 Audit Edition

AppScan 4.0 Audit Edition, the application is a vulnerability assessment tool that accurately detects security vulnerabilities automatically as an integrated component of an enterprise security process review.

Security Testing Features:

• Assessment and analysis is accelerated through tools such as
• Delta analysis that allows security profile comparisons over time
• Accurate, comprehensive automated results analysis on raw data offered for the first time in any risk assessment tool. Such tools combined with comprehensive assessment reports
• best practice remediation steps and real time assessment monitoring tools support the auditor driving ongoing site health checks to ensure the compliance to external regulations and an enterprise's security best practices.
• Developer and Auditor training -

Key concepts can easily and visually be shown any audience. Often with the student able to directly reproduce the simple steps shown to them.

Efficiently dig and poke into any corner of the web application to see if an automated tool missed something, or to test the exposure of a vulnerability that may have been public for some time.

Testing strategy implementation considerations

This paper propose a comprehensive testing strategy for Internet applications, however, it is quite

time-consuming, resources demanding and costly to implement all recommendations. As a result, it is necessary to evaluate the risk involved and the testing requirements depending on the business nature. The major risk areas of e-commerce applications are : e.g. usability, performance, security, availability and functionality. For e-commerce applications, functionality may not be the biggest concern and the shift in risk from functionality towards non-functional issues is dramatic. Most e-commerce systems are simple (at least from the users' perspective) and the four non-functional areas present a challenge to business and testers.

For example, for applications demanding high availability and rapid response time, more resources should be allocated to performance testing. For application requiring high user interaction and ease-of-use, more resources should be allocated to usability testing and navigation testing. For applications requiring high security, more emphasis should be placed on security testing.

In fast-moving e-commerce projects, risk taking is inevitable. Balancing testing against risk is essential because we never have the time to test everything. It's tough to get it 'right'. If we don't talk to the risk-takers in their language we'll never get the testing budget approved.

So, testers must become expert in risk. They must identify failure modes and translate these into consequences to the sponsors of the project. "If xxx fails (and it is likely, if we don't test), then the consequence to you, as sponsor is..." In this way, testers, management, sponsors can reconcile the risks being taken to the testing time and effort.

• The decision to do more or less testing is arrived at by consensus
• The people taking the risk make the decision
  

consciously.

Using risk to prioritise tests means that testers can concentrate on designing effective tests to find faults and not worry about doing 'too little' testing. The decision to release needn't be an uninformed guess. It can be based on an objective assessment of the residual risk.

Adopting a risk-based approach also changes the definition of 'good' testing. The testing is good if it provides evidence of the benefits delivered and of the current risk of release, at an acceptable cost, in an acceptable timeframe. Our testing is good if, at any time during the test phase, we know the status of benefits, and the risk of release.

Testing early in the development cycle, having a clear test plan, an effective test environment, a judicious mix of manual & automated test methodologies, are some guidelines that need to be borne in mind while setting out on the Quality Assurance journey.

The one thing that web-based testers agree on is that testing must be performed very quickly to keep up with the rapid pace of web development. To work closely with marketers, designers, programmers and of course real users to understand both user needs and the technical risks to be addressed in testing. Using ad-hoc processes, tools and environments takes more time than stable environments because you keep re-inventing the wheel. By building a solid test infrastructure designed for flexibility,

you are positioned to react to changes quickly.

An effective way to determine where to start in building a good testing infrastructure is to perform a self-assessment for web testing. Such an assessment can serve multiple purposes and form the basis of an action plan for improvement.

Conclusion

The Web is rapidly becoming the medium of business. Revenues generated through this medium are expected to dominate the revenue pie. The e-commerce application hence has to be absolutely reliable. Any downtime or lack of availability has direct implications on the revenue stream. Moreover, more and more critical operations like financial transactions are being performed on the e-commerce sites, making them vital to business.

To maximize investment in e-business, and even to simply stay in business, a mission-critical e-commerce application must be functional, scalable and perform flawlessly during peak customer traffic. The criticality of testing is thus magnified several times over.

 Business and Technical elements

There are two broad categories under which Quality Assurance elements - factors that define the kind of testing to be performed - can be classified : business & technical.

Business elements are emanated from factors that have a direct connection to the business aspect of the venture.

• Usability : for lack of which customers would not be interested in using the portal.
• Security : without which they would not feel safe doing business with you.
• Reliability : Glitches on this count could mean a dissipation of customer interest.
• Maintainability : The need for which is very high as it is important to keep abreast of new business models &
  

technologies.

Technical elements pertain to the technical foundation on which the site is built.

• Update strategy : required to keep the site rich with increasing functionality.
• Integration : between internal business processes & systems & external interfaces.
• Technology enhancements : which are required to keep the site technologically latest.
• Compatibility : evaluation of compatibility of the system with various elements is a major task, simply because so many different hardware & software environments are possible.

Automated web testing tools

In this paper, we have also proposed a few automated testing tools which can be used in performance (stress and load) testing, security testing, usability testing, navigation testing and regression testing etc. For certain projects, it may be cost effective to set up a test environment, simulating thousands or tens of thousands of virtual users and performing the load and stress tests. To do this, we need an internal lab equipped with appropriate hardware, automated test tools and the required number of virtual user agents.

There are many benefits in using automated test tools for e-commerce applications:

• They can help simplify test processes. E-commerce applications are complex and interactive, so testing must follow complex scenarios. Test tools can automate part of the tedious test processes.
• Investing in automated test tools can improve manual testing with secure, repeatable test cases. This frees developers to work on other tasks.
• Testing a complicated e-commerce application contains many tedious tasks. By using automated test tools, human errors can be reduced.

 User

involvement and continuous improvement

Developers and QA experts are not the only ones who need to work together; business line managers and customer service professionals are also getting in on the act. Business line managers have a considerable say in how the site works, and customer service reps have become an invaluable source of feedback.

To increase the efficiency of the testing process, it's helpful to move past the mindset that says developers write code and the QA people run tests. One practical way to break down that barrier is to attack the problem at the product level-incorporating testing capabilities into the integrated development environment that the developer works in.

The process of improving the site is never complete. Web applications are extremely dynamic. There are multiple parties involved, and things keep changing. In order to keep up, you have to not only test, but monitor performance and tune the applications as well.