on which the risk assessment can be based and committed to delivering an agreed level of quality.
Principle 3. Set clear testing objectives and criteria for successful completion (including test coverage measures). When testing an e-commerce site, it would be very easy for the testing to degenerate into surfing, due to the ease of searching related sites or another totally unrelated site. This is why the test programm must be properly planned, with test scripts giving precise instructions and expected results. There will also need to be some cross-referencing back to the requirements and objectives, so that some assessment can be made of how many of the requirements have been tested at any given time. Criteria for successful completion are based on delivering enough business value, testing enough of the requirements to be confident of the most important behavior of the site, and minimising the risk of a significant failure. These criteria—which should be agreed with the business community - give us the critical evidence that we need in deciding readiness to make the site accessible to customers.
Principle 4. Create an effective test environment. It would be very expensive to create a completely representative test environment for e-commerce, given the variety of platforms and the use of the Internet as a communications medium. Cross-platform testing is, naturally, an important part of testing any multi-platform software application. In the case of e-commerce, the term ‘cross-platform’ must also extend to include ‘cross-browser’. In order to ensure that a site loads and functions properly from all supported platforms, as much stress and load testing as possible should be performed. As an absolute minimum, several people should be able to log into the site and access it concurrently, from a mixture of the browsers and platforms supported. The goal of stress and load testing, however, is to subject the site to representative usage levels. It would, therefore, be beneficial to use automated tools, such as Segue’s SilkPerformer or Mercury Interactive’s LoadRunner, for performance/load testing.
Principle 5. Test as early as possible in the development cycle. It is already well understood and accepted in the software engineering community that the earlier faults are detected, the cheaper the cost of rectification. In the case of an e-commerce site, a fault found after shipping will have been detected as a failure of the site by the marketplace, which is potentially as large as the number of Internet users. This has the added complication of loss of interest and possibly the loss of customer loyalty, as well as the immediate cost of fixing the fault. The fact that e-commerce development is rapid and often based on changing requirements makes early testing difficult, but testing strategies have been developed by the RAD community, and these can be mobilised for support. Perhaps the most important idea in RAD is the joint development team, allowing users to interact with the developers and validate product behaviour continuously from the beginning of the development process. RAD utilises product prototypes, developed in a series of strictly controlled ‘timeboxes’—fixed periods of time during which the prototype can be developed and tested—to ensure that product development does not drift from its original objectives. This style of web development makes testing an integral part of the development process and enhances risk management throughout the development cycle.
Principle 6. User Acceptance Testing (UAT). The client or ultimate owner of the e-commerce site should perform field testing and acceptance testing, with involvement from the provider where needed, at the end of the development process. Even if RAD is used with its continuous user testing approach, there are some