Systems & Software Talk 

Performance Test Estimation

This entry is adapted from a QA Forums discussion at http://www.qaforums.com/ultimatebb.php?ubb=get_topic;f=2;t=002092

Estimation for performance testing is at best, imprecise and challenging.
Assumptions made for the below estimating ideas:
1) Performance Testing is being added late in the development cycle. Performance Testing in this context consists of developing simulated user scripts using simulation tools, where the scripts are intended to apply a defined load against a complete system architecture.
2) The testing is not a repeat using existing test assets.
3) Other roles will be required to either complete or assist with tasks derived from the below outline.
4) The system-under-test exists - or will by the time one is ready to test, and/or an environment is available for simulated user script development.
It is best to have a project planning tool like MS-Project to create an adjustable/adaptable template. This template should address some basics:
1) Project Management / Administration of the performance test project.
1.1) Status reporting, issues reporting
1.2) Scheduling, availability issue management, etc.
2) Performance Test Requirements/Specifications development and reviews.
3) Architectural Analyses of the system-under-test.
4) Security/Firewall/Proxy hurdles handling. Certificates, 3rd party components, etc.
5) Monitoring requirements capture
6) Performance Test Plan development - if applicable. If your specification process is robust enough, a plan can perhaps be omitted.
7) (THIS IS USUALLY THE MOST TIME-CONSUMING TASK)Test data needs identification and creation, or readiness of existing data.
7.1) Data management, security, backup, restore, etc.
NOTES! Some projects may find it less costly to use the performance test tool to create data. Some projects require data scrubbing.
8) Script Development * n scripts
9) Scenario Development * n scenarios
10) Test execution * n executions
11) Results Analyses and Reporting * n test executions
12) Post-project administration
(again - the above is high-level and does not cover all)
Notes:
Protocol complexity, script complexity, skill-sets, unforeseen tools issues**, and so on - can all impact the schedule duration. I haven't covered all, but this should get you going.

** I know of no tool without defects. Some of them are crippling.
Guidelines:
If one estimates a project at less than 120 project hours, and that project requires at least four to eight scripts of moderate complexity - one should look over your numbers again!
Are there ways to compromise? Yes. The compromises go in the RISKS section.