Software Testing Fundamentals

Boundary Value Analysis tests at and just beyond boundary points. The tax boundaries are: $0-$4000 (0%), $4001-$5500 (10%), $5501-$33500 (22%), and $33501+ (40%). Valid boundary tests include values at and just beyond each threshold. $33501 is just beyond the $33500 threshold where the 40% rate begins, making it a valid boundary test case. Options A and C are exactly on boundaries (less ideal), and B ($32001) is in the middle of the 22% bracket.

Equivalence partitioning groups inputs that should be treated the same way. The tax equivalence classes are: $0-$4000 (0%), $4001-$5500 (10%), $5501-$33500 (22%), and $33501+ (40%). Option A shows $5800, $28000, and $32000 - all within the 22% bracket, so they belong to the same equivalence class. Options B spans three different classes (0%, 10%, 22%), and options C and D also span multiple classes.

User Acceptance Testing is primarily manual testing performed by actual end users to verify the system meets business requirements. Automated test execution tools are NOT a characteristic of UAT. UAT involves users testing (B), testing against acceptance criteria (C), and integrating the system with user documentation (D).

To answer this question, the user needs to understand the concept of software reliability.

Software reliability refers to the ability of a software system to perform its intended functions under stated conditions for a specified period of time.

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

A. Be easy to maintain: This option is not necessarily a requirement for software to be reliable. While maintainability is an important aspect of software development, it is not directly related to the system's reliability.

B. Be unlikely to cause a failure: This option is correct. Software should be designed and tested to minimize the likelihood of errors or failures. However, it is important to note that no software system can be completely immune to failure.

C. Never fail under any circumstances: This option is incorrect. It is impossible to create software that never fails under any circumstances. All software systems have limitations, and unexpected events can cause even the most reliable systems to fail.

D. Be written according to coding standards: This option is not directly related to software reliability. While coding standards can help improve the quality of software, they do not guarantee that the software will be reliable.

Therefore, the correct answer is:

The Answer is: B. Be unlikely to cause a failure.

Testing stages (unit, integration, system, acceptance) exist because each stage serves a distinct purpose with specific objectives and focus areas. While staging does make management easier (B) and allows different environment configurations (C), these are benefits, not the primary reason. Having more stages doesn't automatically mean better testing (D is false - stages should be justified by need).

Regression testing involves re-running existing tests after code changes to ensure previously working functionality still works. Test capture/replay tools record manual test interactions and replay them automatically, which is ideal for regression testing where the same tests must be executed repeatedly. Integration (B), system (C), and UAT (D) testing typically involve more varied, exploratory scenarios where capture/replay is less beneficial.

Coverage hierarchy: statement (weakest) < branch < LCSAJ < path (strongest). Each stronger criterion subsumes weaker ones. Statement coverage doesn't guarantee branch coverage (branches may be unexecuted). Branch coverage implies statement coverage. Path coverage detects more faults than statement coverage because it exercises all decision combinations. Statement coverage does NOT detect more faults than branch coverage - branch is stronger, making D the incorrect statement.

A requirement is testable if it can be verified through objective, measurable criteria. Option C specifies 'response time less than one second' with a clear condition ('for specified design load'), making it quantitatively verifiable. 'User friendly' (A) and 'portable' (D) are subjective without defined metrics. '0 faults' (B) is impossible to verify - proving a system has zero faults is theoretically impossible; you can only demonstrate faults exist, not their absence.

The procedure has three distinct paths: single ticket, return standard, and return cheap-day. Executing these three tests covers all questions, decision combinations, and outcomes. Fewer tests would miss paths, while more tests are redundant for basic coverage.

Test coverage criteria measure the extent to which test exercises specific structural elements (statements, branches, paths, requirements). Options A, B, and D describe valid coverage measurements: items exercised by tests, percentage of user requirements covered, and completion criteria. Percentage of faults found (C) is NOT a test coverage criterion - it measures test effectiveness, not coverage. Coverage is about what's tested, not what's found.

Risk-based testing prioritizes areas with the highest probability and impact of failure. While coverage and finding faults are important goals, managing project and product risks is the primary driver of prioritization to optimize limited testing resources effectively.

Test control involves adjusting resources when tests overrun, so v pairs with 3. Test monitoring involves reporting deviations, so w pairs with 4. Test estimation is calculating required resources, so x pairs with 1. Incident management tracks anomalous results, so y pairs with 5. Configuration control maintains records, so z pairs with 2. Option C correctly matches all these pairs.

System testing is typically performed by independent test teams (A is true). Functional (black-box) testing is indeed used more than structural (white-box) testing in system testing (B is true). Faults found during system testing are very expensive to fix because they're found late (C is true). However, end-users are typically involved in acceptance testing, not system testing - system testing is conducted by the test team against specifications, making D the statement that is NOT true.

Not all incidents must be fixed; they can be rejected, deferred, or accepted as known limitations. The other statements correctly define incidents as discrepancies between expected and actual results, which can apply to documentation and assist in process improvement.

Testing is complete when the required level of confidence has been achieved (B is correct). Running out of time (A) is a constraint, not a completion criterion. Finding no more faults (C) is unrealistic - you can never prove absence of faults. The assumption that users won't find serious faults (D) is also not a valid completion criterion. Testing is complete when stakeholder requirements are met and risk is acceptable.

Incidents can be raised against requirements (B is true - ambiguous or incorrect requirements). Incidents do require investigation and correction (C is true). Incidents are raised when expected and actual results differ (D is true - this is the definition). However, incident resolution is NOT the responsibility of the software author (A is false) - it's typically the responsibility of the developer assigned to fix it, not necessarily the original author.

Syntax testing (A) is described in unit test standards. Equivalence partitioning (B) is a standard technique covered. Modified condition/decision coverage (D) is a white-box technique in unit test standards. However, stress testing (C) is typically a system or performance testing technique, not a unit test standard - unit tests focus on individual components, not system-wide stress conditions.

Different failures can indeed have different severities (A is true). A fault need not affect reliability if it's in rarely-used code (C is true). Undetected errors can lead to faults and incorrect behavior (D is true). However, debugging does not necessarily improve reliability (B is false) - the famous 'debugging paradox' where attempting to fix a fault can introduce new faults, potentially decreasing reliability.

Capture-replay tools support multi-user testing (A is true). They are frequently purchased CAST tools (C is true). They capture user behavior (D is true). However, they are NOT used to capture and animate user requirements (B is false) - they capture and replay test inputs, not requirements visualization. Requirements animation is done with prototyping tools, not capture-replay.

Metrics from similar projects (A) help estimate re-testing needed. Discussions with developers (B) help understand what changed and what needs re-testing. Time allocated for regression testing (C) is a budget, not an estimation method. Therefore both A and B together (D) provide the best estimation approach.