As performance testing is integrated into the development lifecycle, one of the key pieces to identify is the performance business processes (BPs). Selecting business processes for performance is very different than what is typically done for QA. Performance BPs should concentrate on mission critical, high volume, and “heavy” transactions. Also, any BPs that currently exhibit poor performance are great candidates for further analysis.
A good rule of thumb to follow during the first few rounds of performance testing is the 80-20 rule. The 80-20 rule in this context concentrates on business processes that make up 80 percent of the overall production volumes while covering only 20% of the application functionality. This rule could potentially cover both the mission critical and heavy volume business processes. Mission critical BPs are normally considered top priority and correlate to any application functionality that drives revenue and/or is critical to the business. Next, concentrate on heavy application business flows that require a lot of interaction with the database. These BPs tend to have heavier foot prints, thus potentially causing overall performance degradation on the system and application under test. Other business processes to take into account would be functionality that currently exhibits poor performance in production. Production testing gives the most accurate results and provides a very good indication of the areas of the application to concentrate on during performance testing.
The four criteria described above provide a good foundation for selecting proper performance BPs for testing. But as the evolution of performance testing, analysis, and tuning matures, the initial sets of use cases are tuned and the next step is to define more granular performance BPs. The first step is to exhaust all flows that meet the criteria described above and tackle them in priority order. The next step would be to expand into functionality that surfaces poor implementation of the application under test. Basically any functionality that performs large numbers of round trip calls, has large request and response sizes, brings back unnecessary data to the front end, has page assets that have not been compressed or optimized, and potentially any other item that could degrade overall performance.
The goal of selecting performance business processes is not to test all the application functionality but to test the business processes that drive the most load, are mission critical, and have the most potential of degrading the system.
About the Author
Brad is a cloud-testing pioneer who joined SOASTA in December 2008. His former roles as head of test and monitoring products at Compuware, Mercury Interactive and Borland prepared him well to disrupt the skeptical and established software quality market with updated approaches and technologies for continuous web and mobile testing.