The 11th Hour

plan.

Our network staff continues by installing the new software. They follow release notes that were prepared by quality assurance in advance. The developers review configuration settings, ensure content is moved to production, and check that the correct files are in place. Once the network, DBA, and developers are done, quality assurance steps in. QA ensures that the release is ready, and that the site is ready to go live again.

What does quality assurance do at four o'clock in the morning with a production Web site on hold? To begin with, there is no time to plan during offline time -you have to be ready to work. We use a checklist that was prepared ahead of time. This reduces release stress and gives quality assurance the ability to ask for other team members to lend a hand in speeding up the process. At this stage, release cycle testing is the same as development cycle testing-planning is essential.

Steps to Checking the Release
Here are the steps our quality assurance team follows to verify the correct release has been installed on each production server.

Use a Specially Created Login Page to Log in to Each Server.
My company uses multiple production servers to support our Web site. We use load-balancing software that pushes each new customer session onto the server with the lowest number of users. While this load balancer is an important element of our production site, it is not helpful when quality assurance or development needs/wants to log in to a particular production server. To work around this issue, our developers built a simplified version of our login page that allows us to specify which production server we want our session to be run on. For our middle-of-the-night installations, this page becomes an important tool as we use the simplified page to log in to each server and ensure each server is ready to go.

Check the Basics First
For each server, some basic elements are checked that have nothing to do with the new release. I make sure I can access each server and log in using a customer account that has been created ahead of time. I also check that basic transactions relevant to our site can be performed (in our case, this means searching for an item, browsing the aisles, putting an item in the shopping cart, submitting an order, etc.).

Ensure SSL is Working on Every Server
SSL (secure sockets layer) is an imperative part of an e-commerce site, because it renders any credit card number entry online reasonably safe. I check SSL to make sure it's working on each production server after every installation. There are secure and nonsecure pages in our site. There are secure pages exposed only to existing customers and secure pages exposed to new customers. I check both, and I check each server.

Like any assessment done by quality assurance, you have to assess risk, likelihood, and impact. How big of a risk would it be to your site if SSL weren't working? How likely would it be for a customer to encounter the flaw? And, could you survive the impact of that flaw on your production site? When you consider these points, checking each secure page on each server is like maintaining your company's own life insurance policy; one that you wouldn't want to skip payment on.

Use a Checklist of Visual Features that Changed for the Release
While most releases contain some functionality change that is not visually noticeable, they may include some change to the user interface such as a newly revamped page or a new