Assume you are the Test Manager for a new software release of an e-commerce application. The server farm consists of six servers providing different…

The main objective stated is to "assure that all the SLAs... will be met before system release." Monitoring SLAs after the system is in production (Option B) is a post-release activity. While essential for operational management and ensuring ongoing performance, it does not contribute to the pre-release assurance goal. The other options represent critical pre-release testing activities within a comprehensive, risk-based performance testing strategy. Unit performance testing (A), static architectural review (D), and system performance testing (C) are all designed to find and mitigate performance risks before the application goes live, directly supporting the stated objective.

A. Perform unit performance testing for each single web service This is an important early activity to isolate performance issues at the component level before they become complex, integrated system-level problems.
C. Perform system performance testing, consisting of several performance testing sessions, to verify if all the SLAs have been met This is the most direct and crucial dynamic testing activity to validate that the complete system meets the specified end-to-end performance SLAs under load.
D. Perform static performance testing by reviewing the architectural model of the system under various load levels This is a highly valuable and cost-effective early testing activity (static analysis) to identify potential design flaws and bottlenecks before any code is written.

1. ISTQB® Certified Tester Advanced Level Syllabus, Test Manager (Version 3.1.2, 2023).

Section 4.3.2, Performance Testing: This section details performance testing as a type of non-functional testing aimed at determining if a system meets specified performance requirements (like the SLA in the question). This supports the importance of options A and C as core performance testing activities. The syllabus implicitly frames these activities as part of the pre-release test process.

Section 4.4, Reviews: This section describes reviews (a form of static testing) as a method to find defects in work products, such as an architectural model. This supports the validity and importance of option D as an early risk mitigation activity.

2. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill.

Chapter 19, Software Testing Strategies: This chapter distinguishes between different testing phases that occur before deployment. It emphasizes component-level (unit) testing and integration/system-level testing as fundamental steps to ensure quality prior to release. This validates options A and C.

Chapter 17, Quality Concepts: The text differentiates between pre-release quality assurance activities (testing) and post-release activities (monitoring). The objective in the scenario is clearly focused on pre-release assurance.

3. Jain, R. (1991). The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling. Wiley.

Chapter 3, Performance Evaluation Techniques: This foundational text outlines three key techniques for performance evaluation: analytical modeling, simulation, and measurement. Reviewing an architectural model (Option D) is a form of analytical modeling. Performing unit and system tests (Options A and C) are forms of measurement. The book presents these as complementary techniques used during system design and implementation to predict and verify performance, reinforcing their pre-release importance.