Topic: Web Testing

Web Testing

How do you test a Web Site anyway? That's the first thing I asked myself when I became the SQA Manager for a dot-com. I knew how to build Web sites, and I had tested several commercial products. It would be easy right? Nope. Not only is it hard, but it can also be expensive.

Performance and Scalability

If you are managing Web site testing for an application that will be used by a large number of people, your number one concern will be performance testing. When several people start using the Web site at the same time, performance may degrade, database transactions might overlap, etc. Your job is to make sure that that doesn't happen.

The first thing you should ask in an interview for Web testing is "will it scale?" Now what does that mean? You want to work on a Web site that is "n-tier." That means that it has at least three layers (tiers). The layer that the user of the site sees is the GUI (Graphical User Interface) layer (also referred to as the front-end or presentation layer). Behind that, in the middle is the middle tier. This is where all the business logic happens. It's also referred to as the application layer. This is where the application servers go. Behind that is the database tier also referred to as the back-end.

In an n-tier architecture, the GUI layer should be concerned with nothing but rendering the Web page and passing transaction requests to the middle tier. No heavy duty calculations should be performed in the user's browser. It should happen on the Web site in the application layer.

The GUI layer must never, ever, ever talk to the database directly. (Side bar: I'd like to point out that I violate these rules everyday - but I'm not developing large commercial n-tier sites).
The middle tier is the heart of the application and the key to scalability. When a user makes a transaction, like filling out a form on the GUI layer, the middle tier is where the transaction is handled. The middle tier will talk to the database and do some of the transaction processing . In , J2EE architecture this layer is written using Enterprise java Beans. In .NET systems, this layer may be written in a language like Visual C#.

The database (back-end) can also play an important role in transaction processing. The first step in improving a Web site's performance can be to move as much of the middle tier logic as possible to stored procedures in the database.

For a Web site to scale, it must be determined how many users a middle tier server can handle. This is done through performance testing. If the middle tier is designed properly, adding another server will double the amount of users that the system can handle. If you can serve up 1 transaction per second for 500 users using 1 middle tier server, then 3 servers should be able to maintain that rate for 1500 users (500 x 3). Though realistically there will always be an acceptable amount of degradation as you add a new server.

No Web site can handle an infinite amount of users. Performance requirements have to be realistic. You may have heard in the news about Denial of Service (DoS) attacks. This is basically performance testing run amok. Hackers hijack a bunch of servers to act as agents and flood a server with transactions until they overwhelm the system. Instead of breaking the system, your job is to determine how many users it can handle before it breaks.