Test Analysis and Design practice questions

6 test cases covering the minimum and maximum of each purchase amount partition.

Why it fails: Calculating only the absolute minimum and maximum values across the entire range ignores the internal boundaries where system behavior shifts, thereby failing to achieve the rigorous fault-detection capability mandated by 2-value boundary value analysis for partitioned inputs.

9 test cases by applying boundary value analysis independently of the loyalty status variable.

Why it fails: Isolating the purchase amount from the loyalty status ignores potential combinatorial defects where specific monetary thresholds intersect with particular customer tiers, leading to incomplete test coverage of the functional business logic requirements.

18 test cases using the 3-value boundary value analysis technique for both input variables.

Why it fails: The question explicitly specifies the 2-value boundary approach rather than the 3-value approach, making this calculation invalid because it unnecessarily multiplies test cases by including interior points not required by the stated methodology.

0.0kg, 5.0kg, 5.1kg, 20.0kg, 20.1kg, and 50.0kg

Why it fails: Including 0.0kg and 50.0kg incorporates minimum and maximum equivalence partitioning values rather than focusing strictly on the specified 2-value boundaries, introducing unnecessary test cases outside the targeted threshold verification scope.

4.9kg, 5.0kg, 19.9kg, and 20.0kg

Why it fails: Using values below the boundaries (4.9kg and 19.9kg) characterizes the 3-value boundary approach rather than the requested 2-value approach, which strictly evaluates the boundary and the immediate exterior or interior neighbor depending on the rule.

4.9kg, 5.0kg, 5.1kg, 19.9kg, 20.0kg, and 20.1kg

Why it fails: This selection mixes the 3-value boundary approach with the 2-value approach by redundantly testing both sides of each boundary simultaneously, violating the strict definitions of a standard 2-value boundary value analysis test set.

4.9kg, 5.0kg, 19.9kg, 20.0kg

Why it fails: Values 4.9kg and 5.0kg test the boundary between the first and second partitions, whereas the question specifically asks for the lower and upper boundaries of the second partition, making this set partially misaligned with the stated requirements.

5.0kg, 5.1kg, 20.0kg, 50.0kg

Why it fails: Testing 50.0kg evaluates the upper limit of the third partition rather than the second partition boundaries. A 2-value BVA strategy focuses exclusively on the specific partition limits requested, rendering this option incorrect for the targeted test scope.

4.9kg, 5.0kg, 20.0kg, 20.1kg

Why it fails: Value 20.1kg falls into the third partition rather than testing the inside neighbor of the upper boundary for the second partition. Boundary analysis requires testing values that reside strictly inside the partitions adjacent to the boundary.

0, 50, 100

Why it fails: This set only tests valid partitions. It fails to check if the application correctly handles values outside the defined range, such as negative numbers or scores exceeding 100. Testing only valid inputs leaves the application vulnerable to crashes or incorrect behavior when users provide invalid data.

0, 1, 99, 100

Why it fails: This set focuses entirely on the valid range and boundary edges. By neglecting values outside the 0-100 range, it ignores the critical error-handling paths where the system should display validation messages or reject input. This incomplete coverage increases the risk of system instability when invalid data is submitted.

-10, -5, 0, 5

Why it fails: This selection is heavily biased towards the lower bound and negative numbers. It fails to test the upper range of the valid partition or values exceeding the maximum limit. Such skewed testing creates a false sense of security and leaves the upper end of the input range untested.

The test suite should be run in a different environment

Why it fails: While environment issues are common, changing the environment does not fix the underlying design flaw of the application. The test design must account for the reality that connections can time out, regardless of the environment. The design should focus on handling the error rather than avoiding it.

The payment module is ready for final release

Why it fails: The error log explicitly reports a timeout error in the database link. Releasing software with known, unhandled connection timeouts is a major risk. The module is clearly not ready, and the test design needs to be updated to address this critical stability issue before any release occurs.

The retry count should be increased from 3 to 10

Why it fails: Increasing the retry count is a configuration change, not a test design activity. Changing the configuration without verifying the impact through testing is poor practice. The test design must first validate the current behavior and then determine if configuration adjustments are necessary to meet system performance goals.

Test execution can begin before analysis is finished

Why it fails: Starting execution before analysis is a recipe for disaster. Execution requires a defined scope and test cases, which are the outputs of analysis and design. Without these, there is no way to know what is being tested or what the expected results should be, leading to unreliable outcomes.

Execution is the only phase where test data is used

Why it fails: Test data must be identified and prepared during the design and implementation phases. If you wait until execution to think about test data, you will face significant delays. Proper data planning is essential for ensuring that the tests can be executed successfully without interruptions or environment-related blockers.

Test scripts are always written during the execution phase

Why it fails: Test scripts should be developed during the design and implementation phases. Writing scripts during execution is highly inefficient and prone to errors. By having scripts ready before execution begins, the team ensures a smooth and continuous testing process, maximizing the time available for actual bug discovery and reporting.

Select only the boundary values 1, 50, 51, and 100 for testing.

Why it fails: Testing only boundaries ignores the internal behavior of the partitions. While boundary value analysis is essential for edge cases, it does not guarantee that the processing logic for mid-range values is correct. Equivalence partitioning requires selecting at least one representative value from each valid partition to ensure functionality.

Test with values 0, 1, 50, 51, 100, and 101.

Why it fails: This approach focuses strictly on boundary value analysis but fails to verify that the core processing logic within the ranges 1-50 and 51-100 operates as expected. Relying solely on boundaries may miss errors in the execution of the main processing routines within the defined valid ranges.

Partition the input into 1-100 and test with random values until coverage is complete.

Why it fails: Treating 1-100 as a single partition ignores the critical requirement that different system components process the ranges 1-50 and 51-100 separately. Random testing is inefficient and non-systematic, failing to provide the level of confidence required by ISTQB standards for structured test analysis and design techniques.

Two test cases.

Why it fails: Testing only two cases covers only half of the potential logical scenarios. In a decision table, failing to test every combination of conditions can lead to missing errors in logic branches, such as how the system handles the 'False/True' or 'False/False' scenarios for access authorization.

Three test cases.

Why it fails: Testing three cases is insufficient because it omits one of the four logical combinations. In decision table testing, it is essential to cover the entire table to verify all business rules. Leaving out one combination creates a blind spot where system behavior remains unverified and potentially defective.

One test case.

Why it fails: A single test case is inadequate for verifying logic involving multiple conditions. It fails to explore how different combinations of inputs affect the system outcome. Decision tables are specifically designed to expose complex interdependencies, and relying on one test case ignores the primary benefit of this technique.

101.

Why it fails: 101 is already covered by the existing test case of 105, which is clearly within the invalid range. While testing 101 is valid, it does not provide as much diagnostic value as testing the exact boundary at 100, which is where the transition in logic is most likely to fail.

98.

Why it fails: Testing 98 is redundant because 99 already confirmed that values within that range are valid. In boundary value analysis, you should focus on the values closest to the transition point to minimize test redundancy while maximizing the probability of uncovering defects related to conditional logic.

106.

Why it fails: 106 is significantly beyond the boundary. While testing it confirms the error persists, it does not help define the exact limit of the valid input range. Professional test design prioritizes values that define the boundaries, as these are the most likely points for logical errors to manifest.

When testing a highly regulated medical device with strict audit requirements.

Why it fails: Regulated environments require rigorous documentation and repeatability, which exploratory testing lacks. In these industries, formal techniques like equivalence partitioning and decision tables are mandatory to provide an audit trail. Exploratory testing would be considered insufficient for meeting the compliance and safety standards required for medical device software.

When ensuring 100% statement coverage for a stable legacy module.

Why it fails: Achieving 100% statement coverage is a formal requirement that necessitates structural white-box testing. Exploratory testing is not systematic and cannot guarantee that every code branch is executed. To meet this specific coverage metric, formal test design based on the code's control flow graph is required.

When replacing all formal black-box test design techniques.

Why it fails: Exploratory testing should supplement, not replace, formal black-box techniques. A robust testing strategy requires a mix of both to ensure that critical business logic is validated systematically while also allowing for the discovery of unexpected issues that only an experienced tester's intuition might find during unscripted sessions.

0, 5, 10, 20, 25

Why it fails: Including 0 and arbitrary midpoints like 10 and 25 mixes equivalence partitioning with boundary testing, failing to focus strictly on the specified 2-value boundary points required for precise error detection at category thresholds.

4, 5, 19, 20

Why it fails: Values 4 and 19 represent points just below the boundaries using the 3-value approach, but the 2-value approach focuses on the boundary value and the immediate adjacent value on the upper side.

4, 5, 6, 19, 20, 21

Why it fails: This set applies the 3-value boundary approach rather than the 2-value approach, incorporating values below, on, and above the boundaries which exceeds the strict definition of the 2-value boundary test technique criteria.

Boundary value analysis

Why it fails: Boundary value analysis focuses exclusively on the boundary values of partitions rather than covering the full spectrum of categorical membership tiers. While useful for purchase amounts, it is insufficient on its own for discrete non-numeric categories like loyalty tiers.

State transition testing

Why it fails: State transition testing is applied when system behavior depends on current states and previous history triggering transitions, which does not align with stateless membership tier discount calculations based purely on discrete categorical input parameters.

Decision table testing

Why it fails: Decision tables handle complex combinations of logical conditions and business rules, but equivalence partitioning is more direct and efficient when dealing purely with single-variable categorical input partitions like simple loyalty tier percentages.

1000, 2500, 5000

Why it fails: This set represents standard equivalence partitioning rather than boundary value analysis. Testing the middle value 2500 does not specifically exercise the logic at the edges of the range. Boundary value analysis requires testing the values immediately at and just outside the limits to detect off-by-one errors in the code.

0, 1000, 5000, 10000

Why it fails: Testing 0 and 10000 tests extreme ranges rather than the specific boundaries of the defined tier. While these might be useful as negative tests, they fail to exercise the specific conditional logic for the 1,000 to 5,000 range, missing potential defects that occur exactly at the threshold of the tier change.

999, 2500, 5001

Why it fails: This set lacks the inclusion of 1000 and 5000, which are the critical boundaries where the system logic must trigger a change. Testing 2500 is redundant for boundary analysis purposes, and missing the actual boundaries prevents the tester from verifying that the code handles the inclusive endpoints correctly for the tier.

Test cases for Admin and User only.

Why it fails: This approach fails to test the time-based condition for the 'User' role. Without checking both in-hours and out-of-hours, the tester cannot confirm if the 'AND time' constraint is correctly implemented in the code, which could lead to unauthorized access during restricted times, violating the stated security policy requirements.

Test cases for all roles at 10:00, 12:00, and 14:00.

Why it fails: Testing multiple times during the day is redundant. Equivalence partitioning suggests that one test within the valid range (09:00-17:00) is sufficient. This set lacks coverage for out-of-hours access, which is a critical boundary condition that needs to be tested to ensure the policy is enforced properly outside of working hours.

Test cases for Admin at all hours.

Why it fails: This only validates the Admin role. It completely ignores the 'User' role logic and the specific time-based constraints associated with it. A decision table must account for all input variables; ignoring the user-role-specific rules means large portions of the system logic remain untested, increasing the risk of production bugs.

To verify that the system can handle concurrent users.

Why it fails: State transition testing focuses on the lifecycle of a single entity, such as a card session. While concurrency is important for overall system performance, state transitions are concerned with the logical flow of a single user's interaction. This test does not provide information regarding the system's ability to handle multiple concurrent sessions.

To ensure that invalid states are unreachable.

Why it fails: While ensuring invalid states are unreachable is a valid test goal, the primary purpose here is to verify that a transition occurs correctly after a specific input sequence (three incorrect PIN attempts). The focus is on the transition logic and the final state, rather than just preventing illegal state transitions.

To test the performance of the ATM hardware.

Why it fails: State transition testing is a logical/functional technique, not a performance or hardware stress testing technique. While the transition may be slow if the hardware is failing, the test objective is the accuracy of the state machine, not the measurement of response times or the durability of the physical ATM components.

2

Why it fails: Two test cases are insufficient to cover all decision outcomes. With only two cases, you cannot test all three branches (minor, adult, senior) and their corresponding false conditions. At least three cases are required to ensure that all logical paths and branching outcomes are properly exercised in this nested conditional structure.

4

Why it fails: Four test cases provide more than the minimum required for 100% decision coverage. While four cases might be useful for boundary analysis, decision coverage specifically asks for the minimum set that hits all branch outcomes. Four cases represent redundant effort, as three cases are mathematically sufficient to satisfy the stated 100% coverage goal.

5

Why it fails: Five test cases is excessive for this specific code snippet. Decision coverage is achieved with fewer tests. Adding more tests does not increase decision coverage beyond the 100% already reached by three well-chosen test cases. This would be an inefficient use of resources in a real-world testing project, violating testing optimization principles.

Statement Coverage

Why it fails: Statement coverage is a white-box technique that requires knowledge of the internal code structure to measure how many lines of code are executed during testing. Because it requires access to the source code and knowledge of the implementation, it is classified as white-box rather than black-box testing.

Control Flow Testing

Why it fails: Control flow testing is a white-box technique that uses the control flow graph of the code to ensure all paths are tested. Because it relies on the internal structure of the software, it cannot be categorized as a black-box technique, which is specifically defined by the lack of code visibility.

Black-box functional testing.

Why it fails: The use of the '--coverage=branch' flag explicitly identifies this as a structural testing activity. Functional testing typically focuses on requirements and input/output behavior without regard for code branches. Conflating the two would result in an incorrect assessment of the purpose of this specific testing command and its resulting report.

Exploratory testing.

Why it fails: Exploratory testing is an informal, experience-based approach where test design and execution occur simultaneously. It does not typically rely on automated branch coverage metrics provided by a tool. The command indicates a formal, planned, and tool-assisted structural analysis, which is the opposite of the ad-hoc nature of exploratory testing.

Usability testing.

Why it fails: Usability testing focuses on how easily a user can navigate the system, which is a non-functional attribute. It is typically evaluated through user trials and qualitative feedback, not by automated code coverage metrics. Branch coverage is irrelevant to measuring user interface usability or user experience, making this an incorrect classification.

Create two separate test cases: one where coupon_valid is true and one where coupon_valid is false.

Why it fails: Varying coupon_valid is pointless because the rule engine ignores that condition entirely for is_member = true and cart_total > 100.00, so both cases execute the identical path and add no coverage. Splitting a condition into true and false cases is the correct technique when each value genuinely alters the rule outcome.

Omit the cart_total variable from the test design entirely because the membership status takes precedence.

Why it fails: Omitting cart_total discards a condition the rule engine evaluates, so the decision table's coupon_valid branch for member carts over 100.00 goes untested. It is tempting because membership appears dominant, and omitting a variable would be correct only where the rule genuinely never references it, such as a condition excluded by the policy's own logic.

Automatically fail the test case because the JSON policy contains a conflicting boolean value for coupons.

Why it fails: A conflicting boolean cannot be inferred: the rule engine simply ignores coupon_valid when is_member is true and cart_total exceeds 100.00, so the condition is irrelevant, not contradictory. Failing the test case is tempting because decision tables normally flag impossible or conflicting combinations, which is the correct response when a policy genuinely defines contradictory outcomes for one rule.

Test cases are derived from the internal code structure, architecture, or detailed design of the software component.

Why it fails: Deriving test cases from internal code structures and architecture defines white-box test techniques rather than black-box methods. Specification-based approaches purposely ignore internal implementation details to maintain independence and focus entirely on external system behavior.

The primary measure of test thoroughness is code statement or decision coverage achieved during execution.

Why it fails: Code statement and decision coverage are structural coverage metrics used exclusively in white-box testing. Black-box testing measures thoroughness through partition coverage, boundary value coverage, or requirements traceability instead of internal code paths.

Testers must have programming skills and access to the source code repository to successfully execute the technique.

Why it fails: Programming skills and source code access are required for white-box testing and static analysis tools. Black-box testing focuses on user interactions, inputs, and outputs, allowing business analysts and testers to operate without developer tools.