Is your company preparing for a capacity test? Are you unsure and uncertain about how to prepare for this test? This article proposes a few strategies to help companies overcome issues such as how to select business processes for a capacity test, the value of automation for a capacity test, and mitigating risk. A poorly coordinated and planned capacity test could prove costly and have a deleterious impact on the end-user's ability to conduct everyday tasks.
Preparing and planning for a capacity test are activities that can prevent many headaches for a company that is expecting to release or deploy an application. Capacity tests are time-consuming and require a great deal of expertise to successfully execute. Below are a few pointers that will help your organization prepare for a capacity test from the very beginning.
Follow the 80/20 Rule
After WWII, Italian economist Vilfredo Pareto discovered that, in Italy, 80 percent of the country's wealth was held by 20 percent of the country's population, hence the 80/20 rule. Moreover, Pareto's observations have led to the creation of Pareto charts and have played a pivotal role in statistical process control (SPC). The Pareto Analysis in SPC operates in this fashion: Eighty percent of problems usually stem from 20 percent of the causes, which leads to the famous phrase "the vital few and the trivial many."
Pareto's principle is also applicable to all types of capacity testing: stress, performance, volume, load, soak, etc. When one applies the 80/20 rule to capacity testing, one can focus on the 20 percent of the business processes that are likely to cause the majority of problems. Pareto's principle allows test managers to select and identify the business processes that are most likely to cause bottlenecks, performance degradation, and traffic across a software application.
An organization can also construct Pareto charts with stakeholders to identify and select business processes that will be tested during a capacity test. Stakeholders in a capacity test could be database administrators (DBAs), infrastructure engineers, middleware engineers, SMEs, developers, business owners, etc.
Seasonal Surges in Demand
Many organizations predict annual business volumes for certain processes such as purchase orders, invoices, and sales orders. These business volumes are then converted into hourly averages. While this approach may correctly emulate average business volumes for a volume test, it overlooks surges in business volumes due to outlier points or seasonal demands that deviate significantly from average volumes.
Examples of surges in business volumes are:
- Insurance and hardware companies experience higher demand for their services and products after a natural disaster.
- Toy stores, retailers, and airlines face increased sales during the holiday season.
- A shipping company has to ship more packages after one of its competitors has a strike.
- Military facilities need to procure more equipment during times of war.
All of these examples converge on a single question: Do these entities have information systems capable of handling an increase in business volumes without degrading end-user response times or becoming inoperable?
The answer to this question is critical. When planning a capacity test, it is essential to discover the operating limits and breaking points of the application under test. It is not sufficient to test an application for average volume; test for volumes that are 20 percent to 30 percent greater than the average volume. The application under test should be scalable and robust enough to handle unexpected or seasonal surges in demand without drastically affecting end-user response times.
Automate for Repeatability and Consistency
Frequently, it will be necessary to repeat capacity tests with multiple sets of data in order to fine-tune a system. The process is as follows: A capacity test is conducted and problems are reported. The responsible parties will then identify the root cause of the problem and repair it. The test engineer will need to repeat the capacity test to determine if the problem has indeed been repaired. This cycle of repeating tests and fixing problems could be time-consuming, resource intensive, and critical to successfully deploying or releasing an application.
It may not be feasible to manually perform a