Software Testing Fundamentals

Under the IEEE 829 Standard for Software Test Documentation, a test plan includes scope, environments, and schedules. A quality plan is a distinct document detailing broader organizational quality assurance processes and metrics.

Reviews and inspections ARE considered part of testing in the broad sense - they detect defects and improve quality before dynamic testing begins. Option A is wrong because being 'before testing' doesn't exclude them from being testing activities. Option B is incorrect - reviews do apply to test documentation. Option D overgeneralizes. Option C correctly states both help detect faults and improve quality.

Performance testing measures how the system performs under load - response time (A), transaction rates (B), and simulating many users (D) are all core performance testing activities. Recovery testing (C) verifies the system can recover from crashes/failures and restore data - this is about reliability and availability, not performance speed or throughput.

Error guessing leverages the tester's experience to find edge cases, making it most effective after formal, systematic techniques are applied. It requires testing experience and is done during testing stages rather than post-live or by end users only.

Failure is the dynamic, observable deviation of the software from its expected behavior or specifications. Defects, errors, and faults are static flaws in the code or human mistakes that can lead to failures during execution.

Technical reviews require active participation from technical staff who examine the work product. This includes analysts who review requirements, developers who review code, and testers who review test cases. Management typically does not participate directly in technical reviews - they may receive summary outcomes but are not participants examining the technical details.

Error guessing is an informal, experience-based technique used to supplement systematic, rigorous testing methodologies. Regression, integration, and system testing are formal levels or types of testing that are part of the main test process.

To solve this question, the user needs to understand the purpose of capture and replay facilities in software testing and the types of testing methods that can utilize them.

Capture and replay facilities are typically used to record interactions with a software application and then replay them at a later time. This can be useful for automating certain types of testing, as it allows testers to quickly and easily repeat a set of actions without having to manually perform them each time.

Now, let's go through each option and explain why it is right or wrong:

A. Performance testing: This option is incorrect. Capture and replay facilities can be very useful for performance testing, as they allow testers to simulate large numbers of user interactions and monitor how the application responds. This can help identify performance bottlenecks and other issues.

B. Recovery testing: This option is incorrect. Capture and replay facilities can also be useful for recovery testing, as they allow testers to simulate various error conditions and test how the application responds to them.

C. GUI testing: This option is incorrect. Capture and replay facilities can be very useful for GUI testing, as they allow testers to automate repetitive tasks such as clicking buttons or filling out forms.

D. User requirements: This option is correct. While capture and replay facilities can be used to test user requirements, they are not typically the best choice for this type of testing. User requirements testing typically involves validating that the software meets specific user needs or business requirements, which may require more complex testing methods.

Therefore, the correct answer is:

The Answer is: D. User requirements.

Branch coverage requires executing each possible outcome of every decision. This code has two decisions: (x>y) with true/false branches, and (x>y) in the while loop with true/false outcomes. Test case 1 (x=3, y=2) covers the if-true branch and while-true. Test case 2 (x=2, y=3) covers if-false and while-false. Two test cases achieve 100% branch coverage.

Cyclomatic complexity V(G) = number of binary decisions + 1 (or more formally, predicate nodes + 1). This is the standard ISTQB definition. Option A describes what V(G) represents, not how to calculate it. Option C describes statement coverage upper bound, not the calculation itself. Option D is vague. Option B gives the correct calculation formula.

Equivalence partitioning creates tests for each equivalence class. The classes are: fail (0-24), pass (25-31), distinction (32-40). Option D tests all three: 32 (distinction boundary), 37 (distinction interior), 40 (maximum/distinction boundary). Options A and B only test one class each. Option C has 30 in pass class but 36 and 39 in distinction class, missing fail class entirely.

Test estimation (1) determines the effort required (b) - calculating resources needed. Test monitoring (3) involves measuring and tracking progress (a) - collecting metrics. Test control (2) takes action based on monitoring, including reallocation of resources (c) when deviations occur. The correct matching is 1-b, 2-c, 3-a (option A).

BS7925-II standard for software component testing defines white-box techniques as those examining internal structure like control flow, data flow, and statement coverage. Syntax testing is a black-box technique that validates input format against a grammar without considering internal code implementation. Random testing is also not a white-box technique, but syntax testing is more definitively a structural black-box method.

White-box testing focuses on internal code structure and logic, not on whether the software meets specified requirements. Using only white-box techniques risks missing requirement gaps because it validates code paths work correctly, not that they implement the right functionality. Black-box testing is essential to verify requirements are satisfied from a user perspective.

Configuration identification (1) requires knowing all CIs and versions (d). Configuration control (2) maintains CIs in a library (a). Status reporting (3) involves recording and tracking problems (c). Configuration auditing (4) checks library contents (b). This mapping reflects standard SCM activities.

To answer this question, the user needs to understand the items that are included in the cost of reviews and the items that are excluded.

The statement says that the cost of reviews will NOT include. This means that the correct option will be an item that is typically included in the cost of reviews, but in this case, will be excluded.

A. Review process itself: This option is typically included in the cost of reviews, so it is not the correct answer.

B. Metrics analysis: This option is typically included in the cost of reviews, so it is not the correct answer.

C. Tool support: This option is typically included in the cost of reviews, but the statement says that the cost of reviews will not include it. Therefore, option C is the correct answer.

D. Process improvement: This option is typically included in the cost of reviews, so it is not the correct answer.

The Answer is: C. Tool support.

Internet banking primarily requires non-functional testing including security, performance, reliability, and availability. While functional testing validates transactions work correctly, the critical aspects for banking are security (authentication, authorization, encryption), performance (response times), and reliability. These are non-functional attributes.

Dynamic analysis tools examine software while it's running, making them effective for detecting runtime issues like memory leaks and dangling/unassigned pointers. Static analysis examines code without execution and can identify potential issues but cannot detect actual runtime memory behavior.

Dynamic analysis tools examine software while it's running, making them effective for detecting runtime issues like memory leaks and dangling/unassigned pointers. Static analysis examines code without execution and can identify potential issues but cannot detect actual runtime memory behavior.

Test Plan is a management document that outlines testing strategy, scope, resources, and schedule. It includes features to test, environmental needs, suspension/resumption criteria, and approach. Expected results are part of Test Cases, not the Test Plan itself.