Software Testing and Quality Control

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.

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.

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.

With limited time, prioritize testing business-critical areas (1) and fault-prone areas (2). Testing easiest functionalities first (3) is poor risk management - it wastes resources on low-risk areas while critical features may remain untested. Risk-based testing prioritizes by business impact and technical risk.

Testing amount should be determined by risk level, contractual obligations, and legal/safety requirements. Test data is what you use during testing, not a factor in deciding how much testing to perform. The volume of test data doesn't drive testing scope - risk and requirements do.

Computer-Aided Software Testing (CAST) tools yield the highest cost savings in test execution because they automate repetitive test run processes. Planning, design, and management still require heavy manual effort and cognitive input.

Testing's primary objectives are finding faults, improving quality, and validating usability/non-functional requirements. Testing evaluates rather than directly improves accuracy - developers fix faults to improve accuracy. Testing identifies issues but is not itself the mechanism that improves software precision.

Software quality attributes include correctness (does it work), usability (ease of use), and reusability (can components be reused). Viability refers to business feasibility/market success - an economic concept outside technical quality dimensions. Quality engineering focuses on technical attributes, not commercial viability.

Incidents merit investigation, but not all require resolution. Some may be duplicates, misunderstandings, or accepted risks. Incidents do occur when expected and actual results differ (B is true). They can be analyzed for test process improvement (C is true), and can be raised against documentation (D is true). Only A is false.

Non-functional testing evaluates system attributes like usability, performance, and reliability rather than specific functionality. Usability testing assesses how easily users can interact with the system, which is a classic non-functional test. Statement coverage and dataflow testing are white-box structural techniques, while cause-effect graphing is a black-box functional test design method.