Drag and Drop Question A software security engineer is developing a black box-based test plan that will measure the system's reaction to incorrect or illegal inputs or unexpected operational errors…

Question

Exhibit

Answer Area

Explanation

Black Box Testing Techniques - Drag & Drop Explained

Context

The scenario describes black box testing focused on how a system handles bad inputs, illegal data, and unexpected situations. The techniques are ordered by their logical application in a test design workflow - from basic input partitioning to complex behavioral modeling.

Correct Arrangement & Reasoning

1. Equivalence Class Analysis

Foundation: partition the input space

The starting point. You divide all possible inputs into equivalence classes - groups where the system should behave identically. Critically, this includes invalid classes (illegal/incorrect inputs). Testing one value from each class is sufficient to represent the whole group.

• Why first? You must define what input domains exist before you can test their edges or combinations.

2. Boundary Value Analysis

Refinement: test the edges of those classes

Once equivalence classes exist, you test at their boundaries (min, max, just-above, just-below). Most defects occur at the border between valid and invalid input ranges.

• Why second? It directly extends equivalence class analysis - you need the class boundaries defined before you can test them.
• Common mistake: Treating BVA as independent of equivalence classes. They are complementary; BVA is a refinement of ECA.

3. Decision Table Analysis

Complexity: test combinations of conditions

When system behavior depends on multiple simultaneous conditions, decision tables map every combination of inputs to expected outputs/actions. Catches defects in logic involving AND/OR conditions.

• Why third? After individual inputs and boundaries are handled, you address interaction effects between inputs.
• Common mistake: Using decision tables for simple single-variable inputs - overkill there; they shine with multi-condition logic.

4. State-Based Analysis

Behavior: test system reactions across states

Tests how the system transitions between states in response to events - including unexpected operational errors and illegal sequences. Verifies the system doesn't enter invalid states.

• Why last? It models system behavior over time, not just input/output pairs. It addresses the "unexpected operational errors and situations" part of the prompt directly.
• Common mistake: Confusing this with decision tables - decision tables test conditions -> actions; state-based testing tracks the system's current state as a variable itself.

Summary Table

The progression moves from simple input partitioning -> edge cases -> combinatorial logic -> stateful behavior, mirroring how a rigorous black box test plan is typically designed.

No community discussion yet for this question.