background image
<< Determine the Process | Identify performance acceptance criteria >>
<< Determine the Process | Identify performance acceptance criteria >>

Determine Compliance Criteria

approval, but it is still better to submit the performance-testing process concept before the project
launches than afterward.
Determine Compliance Criteria
Regulatory and compliance documents may be harder to obtain because they often are not made
readily available for review by non-executives. Even so, it is important to review these standards.
The specific language and context of any statement related to testing is critical to determining a
compliant process. The nature of performance testing makes it virtually impossible to follow the
same processes that have been developed for functional testing.

For example, when executing a performance test simulating hundreds of users, if three of those
users record response times that do not achieve the documented requirement, does that
requirement pass or fail? Which test case does that count against, the one that sets the response
time, the volume, or the workload? Does the entire test fail? What happens to the thousands of
other measurements collected during the test? Do those three failing measurements get one
defect report, or three, or none, because the average response time was acceptable? These are the
kinds of questions you will likely face and need to resolve based on whatever specific standards
have been applied to your project.

Once you understand both the process and the compliance criteria, take the time to get your
interpretations approved by an appropriate stakeholder. Compliance is not your specialty;
performance testing is. Get help when you need it.
Activity 2. Understand the System and the Project Plan
Once you have a firm understanding of the process and compliance requirements, the next step is
to establish a fairly detailed understanding of the system you are to test and the project specifics
for the development of that system. Again, in a CMMI-type project, there are usually many
documents to read and project plans to reference. These may include use case documents and
models, state-transition diagrams, logical and physical architecture diagrams, storyboards,
prototypes, contracts, and requirements. Although all of these documents are valuable, even
when taken together, they frequently do not contain all of the information you will need in order
to create an adequate performance test plan.
Understand the System
The information about the system contained in these documents is frequently abstracted from the
end user in such a way that it is difficult to envision how individuals and groups of users will
interact with the system. This is where you need to put your business analyst skills to use. Some
of the things you will want to make sure you understand include:
·
Who or what are the users of the system? What are their reasons for using the system, their
expectations, and their motivations?
·
What are the most frequently occurring usage scenarios for the system?
·
What are the business-critical usage scenarios for the system?
·
What are the different ways that a user can accomplish a task with system?
·
How frequently will a user access the system?
·
What is the relative distribution of tasks that a group of users will conduct over time?