Determine Overall Objectives
Approach for Determining Performance Testing
Objectives
Determining performance-testing objectives can be thought of in terms of the following
activities:
·
Determine the objectives of the performance-testing effort.
·
Capture or estimate resource usage targets and thresholds.
·
Capture or estimate resource budgets or allocations.
·
Identify metrics.
·
Communicate results.
·
Stay aware of changing objectives, targets, and budgets.
These activities have been discussed in detail in the following sections.
Determine the Objectives of Performance Testing
The methods described in this chapter have proven effective in performance-testing
projects. Whether you apply these methods precisely as stated or adapt them to fit your
specific project and work environment is unimportant. What is important is to remember
that objectives are intentionally collaborative; that is, they are a tool for helping to ensure
that the performance-testing effort provides great value to the team -- in particular the
architects, developers, and administrators -- as early as possible in the project life cycle.
Determine Overall Objectives
The first task is to determine the overall objectives for the performance-testing effort.
Some common objectives include:
·
Determine if the application complies with contracts, regulations, and service level
agreements (SLAs).
·
Detect bottlenecks to be tuned.
·
Assist the development team in determining the performance characteristics for
various configuration options.
·
Provide input data for scalability and capacity-planning efforts.
·
Determine if the application is ready for deployment to production.
Review the Project Plan
Review the project plan with individual team members or small groups. Remember that a
project plan does not have to be in the form of a document; for example, it may be a
whiteboard sketch, a series of e-mail messages, or a vague idea in the minds of various
team members. The point is that no matter how informal the project plan might be, every
project has some sort of underlying plan. While reviewing or extracting the plan,
whenever you encounter something that looks like a checkpoint, iteration, or milestone,
you should ask questions such as:
·
What functionality, architecture, and/or hardware will be changing between the last
iteration and this iteration?
