Chapter 3 places performance testing inside the wider process: how the principal activities map onto planning, monitoring and control, analysis, design, implementation, execution and completion; the categories of performance risk that belong to different architectures; how those risks appear across the development lifecycle; and how the work changes in sequential, iterative and Agile settings and when software is bought rather than built.
This is the first chapter where analysis-level questions appear. They do not ask you to recite the nine architecture categories — they describe one system and expect you to name the risks that actually belong to it. A flat memorised list produces confident wrong answers here, because several categories share vocabulary. Study by architecture: for each one, what fails, and what measurement would show it.
Where candidates lose these points:
Attaching a risk to the wrong architecture. Battery, memory, device temperature, sensors and connection quality are mobile. Self-scaling rules and misconfiguration are dynamic or cloud-based. Predictable behaviour newly exposed through APIs and web services is mainframe. Safety criticality and hard deadlines are embedded real-time. Connection speed, congestion, public Wi-Fi, firewalls, packet inspection and load balancing are client-server. The distractors are all real risks — just of a different category.
Assuming the supplier owns performance for bought software. For commercial off-the-shelf products the acquiring organisation carries the performance testing responsibility, and the product has to be treated as a black box configured to local needs.
Confusing a control measure with an analysis activity. Adjusting the volume of generated load, replacing or adding hardware, and changing the network or the software are control measures — they belong to monitoring and control. Reviewing requirements, service level agreements, the IT architecture and capacity planning belongs to analysis.
Reporting residual risk qualitatively when the data supports a number. Express it quantitatively — for instance the proportion of users still exceeding a latency threshold — and remember that failed transactions count towards the miss, not only slow ones.
Treating Agile performance testing as the same work done later. The syllabus puts it in the first iteration or a dedicated one, with continuous integration implications, non-functional user stories and production monitoring. Sequential lifecycles instead verify performance phase by phase and carry performance criteria as acceptance criteria.
Skipping the four-step risk process. Risks are identified, assessed, mitigated and then re-evaluated against what the test actually showed. Questions that describe a mitigation without a re-assessment are describing an incomplete process on purpose.
This chapter is covered most heavily (7 questions) in CT-PT — Mock Exam 1 (Performance Testing Tasks, Load Profiles and Metrics), CT-PT — Mock Exam 2 (Resource Saturation & Bottleneck Diagnosis), CT-PT — Mock Exam 3 (Distributed Systems, Garbage Collection and Cluster Analysis)