Identify and Test High-Risk Operations
As I described in my previous post on choosing test scenarios, the early tests should focus on the high-traffic scenarios. After testing and optimizing those, the next step is to identify and test the rarely-used but high-risk operations. These are operations that may have an impact on performance that is not proportional to their frequency. Even though these are not as common, they can have large impacts due to their system-wide nature and can cause sporadic performance drops during production hours that defy explanation.
Examples include:
- Complex searches
- Updates that touch many joined tables at once
- Mass changes to data that affect many rows
- Large or complex reports
- Administrative functions, such as data migrations, data cleanup or consolidation, cache clearing, etc
- Backups
For many sites, these operations may be so rare that additional testing effort cannot be justified. In this case it is wise to include these in the final testing report – so that that the project managers / sponsors / stakeholders understand that these scenarios exist, they are high-risk and they have not been tested.
Chris Merrill, Chief Engineer
When his dad brought home a Commodore PET computer, Chris was drawn into computers. 7 years later, after finishing his degree in Computer and Electrical Engineering at Purdue University, he found himself writing software for industrial control systems. His first foray into testing software resulted in an innovative control system for testing lubricants in automotive engines. The Internet grabbed his attention and he became one of the first Sun Certified Java Developers. His focus then locked on performance testing of websites. As Chief Engineer for Web Performance since 2001, Chris now spends his time turning real-world testing challenges into new features for the Load Tester product.