While identifying a problem, I always keep the A.C.E model in mind. A.C.E stands for Assess, Contain, Eliminate. Let me explain how the A.C.E model works as a trouble-shooting tool for development testing, after the launch of a website.

A. Assess. Trace the site or application activity from the launch date to the day the problem first occurred. Use any original or back-up data that you have on hand and compare it to the client copy. If there is something that was added or taken out, find out why. It could be a simple solution if the problem stems from something environmental or technical. Find out if there have been any changes (major or minor) in the client’s capacity to host the site or application (i.e. switched hosting companies, bought a new server, etc.).

Also look for any irregularities or errors that would not have come up during testing—things like too many user requests (a common issue in commercial sites or sites for huge corporations). Let the client know that an application or site designed to handle 10,000 unique visitors may have trouble handling hundreds of thousands, since the requests to view and use the site will lead to denial of service.

It is prudent to look at the type of hardware in use to narrow down any problems before and after the launch. We test using the minimal requirements of a site, knowing that if it works using moderate to contemporary equipment, it will work with cutting edge server equipment. Once the problem has been assessed and identified, we move to the next stage.

C. Containment. Whether it’s a small programming bug or a major error, it is the responsibility of the tester to be candid to the client about the extent of the situation. There are numerous factors as to why the bug got past the testing phase, such as not enough testing time, launch was pushed ahead of schedule, or the like. But the fact of the matter is the problem exists, and it has to be dealt with.

A tester would be able to contain the problem and anticipate if the solution could accidentally cause another issue. In this case, the best course of action would be to not take the application or site offline, but to limit outside access to the resource. It wouldn’t make any sense to continue to grant access to something that, in the user’s mind, does not work.

At worst, the application or site would have to limit user access for a few days until everything is corrected and functional. It is in the client’s best interest to welcome user feedback, as this feedback could improve client interaction. Now that there is an understanding of the expectations and requirements of the client, this knowledge can be applied to the next project.

E. Elimination of issues can take many forms but the results are always the same: resolution of outstanding issues and client satisfaction. No matter what the cause, it is important to learn from the recent crisis (and believe me, to the client, it was a crisis). For the next project, the professional will remember the causes of the issue and can take a different approach. In turn, the client can plan ahead and adjust for extra testing and leeway in case of delays.

The goal of research and the A.C.E model is to make sure that anything we do as professionals is up to the standards of our clients. Anyone with the right training can make an application or website and make it look pretty. But a professional will take into account the client’s individual needs, user expectation, and the scalability of the end product.

This methodology and practice, as outlined above, has obvious benefits, such as limiting usage while testing and Q&A occurs, as well as setting client expectations for deployments and quality control throughout a project, as well as during those critical days after launch. The world of software, like many other technical fields, present its own core list of challenges and we aim to achieve the highest level of stability and consistency for the websites we build.