Successful deployment of electronic commerce applications: process is key

Are you in search of a silver bullet?

A successful electronic commerce application is secure, robust, scaleable, reliable, maintainable and highly available. Typical electronic commerce applications involving business-to-consumer commerce models are rolled out in three to six months, and the schedules for development and deployment are extremely stringent. In order to build an electronic commerce application, you most often need to integrate one or more of the following components:

• database server
• server-side application scripts/programs
• application server
• HTML forms for user interface
• application scripts on the client
• payment server
• scripts/programs to integrate with legacy back-end systems

Development issues

The process of developing an electronic commerce site is significantly different from developing a marketing Web site -- commerce-enabling adds another level of complexity. One main issue when developing and deploying an electronic commerce application is the complexity of product integration.

If you are developing an application which uses a database server, Web server and payment server from different vendors, there is considerable effort involved in installing all these components, understanding connectivity-related issues and integrating them into a single development environment. If you need to integrate any legacy system code with the application, that also adds a new dimension to the problem, since you will have to invest time in understanding the interfaces for the legacy system code.

It's also crucial to keep in mind the steep learning curve associated with cutting-edge technologies. Keeping pace with latest versions of the development tools and the various products to be integrated, their compatibility with the previous versions and investigating all the new features for building optimal solutions for performance can be a daunting task. Also, since electronic commerce applications on the Web belong to a whole new realm, you'll likely find that there are no metrics available from similar past projects which you can refer to when trying to make reasonable time and cost estimates for developing the application.

It is important to pay attention to certain areas which have the potential of becoming very complex. Designing and implementing elaborate test suites to test all the different components and aspects of the application is an example. The maintenance tasks of installing and upgrading the application can get very involved as well, as they demand expertise in database administration, Web server administration, payment server administration, and administration of any other special tools that have been integrated into the site. Technical support is another area to keep in mind. If the development environment and target deployment environment are different, the remote installation of the servers required for the application to run at the client site can become complex.

Application development process

Having a well-defined software development process goes a long way towards reducing the complexity. An incremental model for development addresses most of the issues mentioned above in successfully rolling out electronic commerce applications. The most effective way to develop an e-commerce Web site is to first set up the development environment, build a skeleton system with stub functions and then incrementally add functionality. This method facilitates early testing of the system and also helps the developers and QA engineers unearth any potential architectural issues or connectivity issues among the various products. A project using an incremental model of development consists of three distinct phases: product installation phase, incremental development and testing phase and application deployment phase.

Product installation phase

When setting up the development environment, it is imperative to document the process of installation and all the issues and resolutions related to connectivity of the various components of the system. This document will be of immense use at a later stage, when you need to deploy the application in the production environment.

Incremental development and testing phase

It is important to outline all the basic functional requirements of the application and also specify a framework for the application architecture. This establishes a baseline of features for the application and should evolve as you incrementally add features to the application.

In an incremental development environment, establishing coding standards greatly helps program comprehension and aids in modifying the source code to add new features. Most often, changes in the user interface layout surface during the final stages of application development. Separating the user interface code from the application code early on in the project definitely aids in incorporating changes.

There are eight areas that encompass complete QA testing:

1. unit testing
2. functional testing
3. usability testing
4. smoke testing
5. regression testing
6. cross-platform (including cross-browser) testing
7. stress/load testing
8. user acceptance/field testing

Developers are responsible for unit testing, which is the testing of each feature or functional "unit" of code. Each functional component of a Web site should be unit tested before it is integrated into the complete system. In a commerce-enabled Web site with a database component and a credit card processing component, you should unit test the database and the credit card processing components separately before integrating them into the system together.

Functional testing involves manual testing of all of the functional areas of a site to insure that they work properly for users. Functional areas include each of the major areas of the site as seen by users, and functional testing should exercise all of the options and features available to the users. As part of the functional testing effort, you should run a link checker such as the Microsoft Site Analyst program on the development site -- and ultimately on the live site -- for Web sites under development. If you run a link checker regularly, you can track the overall progress on the site in terms of broken links and various other errors and statistics relevant to all Web sites.

At some point during unit testing or functional testing, QA engineers should perform a basic level of usability testing, which involves checking for user-friendliness, and a logical flow of operations of the Web site from the user's point of view. (For example, on a data-entry form, the developer's choice of field types should be examined for ease of data entry and ease of standardizing the input values.) Usability testing should be performed as early as possible in the development cycle, when the QA engineers are the least experienced with the product and hence the most objective. Also, addressing usability issues early in the project cycle allows developers to make any needed changes before the site becomes more complicated and hence more risky to change.

It is a good idea to write an automated "Smoke Test" for an e-commerce Web site using a scripted testing language such as the Segue SilkTest language. A Smoke Test is a high-level automated test which "touches" on all areas of the functionality of the Web site being tested. The goal of the Smoke Test is to achieve breadth of testing, rather than depth in any particular area, and is intended as a "first-pass" check for any new bugs or anomalies that occur during a site update or move. You should run the script for each full or incremental release of the application, and also before and after a site is moved (i.e. from a development area to its live area).

The Smoke Test should be written near the end of the Web site development cycle, for two reasons. The Smoke Test should cover as many areas of a site as possible, hence it is best to write the script when most of the functionality is complete. Also, because an automated test script sees any change as a bug, it is best to create and run the test after the user interface and major functionality have stabilized.

Regression testing should be done on an ongoing basis as developers notify QA of fixes and changes. Regression testing is the re-testing of bug fixes or changes after the bug fixes and/or changes have been submitted and posted to the site.

Besides verbal communication, the vehicle for communicating information about fixes and changes should be an agreed-upon area (ideally in the form of a database or electronic bulletin board) on or linked to the project's development area. Once developers post notification messages about submitted fixes and changes in response to bug reports, QA engineers should re-visit the affected areas and those immediately around the affected areas, and if the fix was effective, the QA engineers should post another message closing out the problem.

Cross-platform testing is an important part of testing any cross-platform software application. In the case of e-commerce Web site development, the term "cross-platform" must also extend to include "cross-browser." In order to insure that a site loads and functions properly from all supported platforms, you should at minimum load the site and check basic functionality on each platform and browser the client wishes to support. Typically the following browsers and platforms should be assumed unless otherwise specified:

• Browsers: Last two full versions of Netscape Navigator and Navigator Gold, and Internet Explorer

• Platforms: Windows 95, Windows NT Client, Macintosh

In addition to testing on the different platform and browser combinations, it is also a good idea to vary the hardware configurations on the machines used for testing. Differences in screen resolution, processor speed, amount of available RAM, and whether the machine is connected to the Internet via LAN or dial-up connection can greatly affect how a Web site looks and performs

As much stress and load testing as possible should be performed on completed e-commerce sites. At minimum, several people should be able to log in to the site and access it concurrently, from a mixture of the various browsers and platforms supported. The goal of stress and load testing is to subject the site to usage levels it is likely to see once it is deployed.

In addition to manual load testing with multiple human users, there are now tools, such as Platinum Technology's Webload and Mercury Interactive's LoadRunner, that can automate stress and load testing on Web sites by simulating usage by multiple clients. If technical limitations of the site or development environment (i.e. limited connections permitted by licensing agreements, or firewall issues) don't prevent the use of such tools, these tools enhance your ability to stress and load-test web sites beyond the human resource-dictated constraints.

The client or ultimate owner of the e-commerce Web site should perform field testing and acceptance testing, with involvement from the provider where needed. The scope of the provider's internal testing coverage and user acceptance testing coverage should be defined early in the project development cycle, and revisited again as the project nears completion, to assure continued alignment of goals and responsibilities. Acceptance testing usually consists of functional testing performed by the client, but may sometimes include stress and load testing, automated testing, or additional cross-platform/cross-browser testing.

Application deployment phase

When it is time to deploy the completed application, you will first need to install and re-integrate the various products in the live production environment. At this time, you can reuse the documents from the product installation phase for the development environment to help you through the process.

Once the various products are installed in the production environment, you can then copy the application code to its newly-configured location. The detailed instructions from the product installation phase on how to install the application can also be useful to the Webmaster when moving the application from the development server to the production server.

The process of developing and maintaining an electronic commerce site can be a very challenging and interesting endeavor, but having well-defined development processes with minimal overhead could provide the path to success.

Until recently, Barbara Grimm was the quality assurance manager for USWeb Boston. She has previously held positions in Software QA and QA Management at several small software companies, as well as hardware engineering at GE Aerospace and now runs a successful independent consulting practice. Barbara holds a BSEE from Worcester Polytechnic Institute and an MBA from Northeastern University. She can be reached at bgrimm@tiac.net

Suchithra Dorbala was previously a senior software engineer at USWeb Boston, where she developed electronic commerce applications. She has worked on several software projects in the areas of medical systems, telecommunications and user interfaces. She holds a BS in Information Systems and an MS in Software Systems from BITS, Pilani, India. Suchithra can be reached at sdorbala@us.oracle.com.