The ‘Test Basis’ is the body of knowledge used as the basis for test analysis and design. A tester’s key responsibility at this stage is to evaluate the quality of the requirements or acceptance criteria themselves. The primary concern is ensuring the criterion is clear, unambiguous, and testable, as this forms a solid foundation for subsequent test design. The other options relate to detailed test design or implementation, which come later.

While confirmation testing (re-testing) would be used to verify the specific bug is fixed, the question asks to also ‘check for unintended side effects.’ This broader check to ensure that modifications haven’t adversely affected other parts of the system is the definition of regression testing. It often includes re-testing the fix as part of its scope.

Equivalence partitioning involves dividing input data into valid and invalid partitions. The most effective approach is to identify meaningful boundaries. For a transfer amount, key boundaries are zero (negative/positive) and the maximum transfer limit. Option 2 correctly identifies these distinct partitions: invalid negative, boundary of zero, valid values below the limit, the boundary value of the limit itself, and invalid values above the limit. This covers all significant cases concisely.

The principle of ‘Early testing saves time and money’ states that testing activities should start as early as possible in the software development lifecycle. Finding and fixing defects early, during requirements or design, is significantly less costly than finding them in production. Involvement in iteration planning and early test design is a direct application of this principle.

Exit criteria are a set of conditions agreed upon to formally conclude a test phase. Common criteria include requirement coverage, test case execution, and defect status (e.g., no high-severity defects open). The scenario describes meeting execution/completion criteria but failing the quality/defect criterion due to open high-severity issues. This is a clear case where some, but not all, exit criteria are satisfied, preventing release.

System testing is the test level where the complete, integrated system is evaluated against specified requirements, including non-functional requirements like reliability, security, and safety. For safety-critical systems, system testing is where rigorous validation against external standards (like FDA regulations for medical devices) and detailed risk analyses are performed. Acceptance testing focuses on user/business needs, while component and integration testing focus on structural and interaction issues.

This scenario relates to the principle of ‘Defensive Design’ and robustness. A key testing mindset is to anticipate unexpected or invalid input. A system crash on a simple special character is a robustness failure. The tester’s role is to advocate for software that behaves in a predictable and stable manner even with incorrect input, typically by providing a clear error message, not by failing catastrophically.

The core tenet of risk-based testing is to prioritize and focus testing efforts based on the assessed risk. A high-risk item warrants more intensive testing effort. This typically means starting testing earlier, allocating more skilled resources, designing more and/or more detailed test cases, using more rigorous techniques (like boundary value analysis), and potentially executing them more frequently. It is the opposite of being deferred or de-prioritized.

Entry criteria are pre-conditions that must be fulfilled to start a test phase. They are agreed upon to ensure testing is conducted under valid conditions. If a criterion is not met, starting testing risks wasted effort, false defect reports, and invalid results. The proper action is to escalate the blockage. The decision to waive or change the criterion should be a conscious, documented decision by the project stakeholders, not an automatic adjustment by the tester.

The ‘Test Basis’ is the body of knowledge used as the basis for test analysis and design. A tester’s key responsibility at this stage is to evaluate the quality of the requirements or acceptance criteria themselves. The primary concern is ensuring the criterion is clear, unambiguous, and testable, as this forms a solid foundation for subsequent test design. The other options relate to detailed test design or implementation, which come later.0