Static Testing practice questions

Any readable work product can be reviewed, but static analysis also needs a structure against which the work product can be checked.

Static analysis is tool-supported, so the tool needs rules to apply. Models, code and text with a formal syntax provide that structure. The interview summary, the sketches and the narrative charter are all valid review targets, which is what makes them tempting, but they lack the formal structure a tool would need.

1. Notice that the stem asks for automatic, tool-based checking.
2. Recall that static analysis needs a formal structure to check against.
3. Find the only work product with a formal syntax.
4. Choose the design model.

Exam tip: Reviews need readability; static analysis needs structure.

Static testing does not execute the software under test; it relies on manual examination (reviews) or tool-supported evaluation (static analysis).

The defining feature of static testing is that nothing is executed. Every distractor describes running the software in some way: comparing results, measuring performance or rerunning tests. Those are forms of dynamic testing.

1. Look for the option in which nothing is executed.
2. Recall that reviews and static analysis evaluate work products directly.
3. Rule out every option that runs the software.
4. Choose examining work products without execution.

Exam tip: Static = no execution; dynamic = execution.

The objectives of static testing include improving quality, detecting defects and assessing characteristics such as readability, completeness, correctness, testability and consistency.

Static testing examines work products as they are written, so its objectives are about their quality characteristics and the defects they contain. The distractors all describe goals that need the software to run: measuring response time, confirming a fix and reproducing a failure.

1. Recall that static testing evaluates work products without running them.
2. Check which goal can be met by reading a work product.
3. Rule out goals that depend on execution.
4. Choose assessing readability, completeness and testability.

Exam tip: Static testing assesses how good a work product is before anything runs.

Static testing can be used for both verification and validation, and it complements dynamic testing rather than replacing it.

Static testing checks whether a work product meets its specification (verification) and also whether it meets stakeholders' needs (validation), for example when business representatives review requirements. The verification-only option is the near-twin: it is half right. No test cases are needed to review a document, and static testing complements rather than replaces dynamic testing.

1. Recall the two purposes static testing serves: verification and validation.
2. Remember that reviews involving stakeholders validate requirements against real needs.
3. Recall that static testing needs no test cases and complements dynamic testing.
4. Choose the statement covering both verification and validation.

Exam tip: Static testing verifies and validates; it never replaces dynamic testing.

Static testing can detect defects in the earliest phases of the SDLC, fulfilling the principle of early testing.

A defect found in a requirement before design and coding starts costs far less to fix than one found after it has spread into code and tests. That is the main value of static testing for cost. The other options either describe late, dynamic activity or claim that later testing can be dropped, which the syllabus does not support.

1. Recall the early testing principle: defects found early cost less.
2. Notice that static testing needs no running software.
3. Rule out options that skip or remove later testing.
4. Choose detection in the earliest phases.

Exam tip: Early defect detection is the cost case for static testing.

Some defects can only be found statically, such as unreachable code, design patterns not implemented as desired, and defects in non-executable work products.

Dynamic testing finds defects through the failures they cause when the code runs. Unreachable code never runs, so it can never cause an observable failure; only examining the code finds it. Each distractor produces a visible failure when the right test is executed, so dynamic testing can find it.

1. Ask whether each defect can ever cause a failure during execution.
2. Notice that unreachable code is, by definition, never executed.
3. Recall that defects without failures can only be found by examination.
4. Choose the unreachable code.

Exam tip: If code can never run, only static testing can find its defects.