Testing Throughout the Software Development Lifecycle practice questions

The SDLC affects the scope and timing of test activities, documentation detail, techniques and approach, the extent of test automation, and the role and responsibilities of testers.

Moving to Scrum shortens the delivery cycle, so regression testing must be fast and is largely automated, and testers become members of a cross-functional team with different responsibilities. The remaining options describe a testing principle, a core execution task and a glossary definition. They are true in both models, so the change of lifecycle does not alter them.

1. List what the SDLC influences.
2. Match automation extent and tester role to that list.
3. Eliminate principles, core tasks and definitions that apply in every model.
4. Choose automation extent and tester role.

Exam tip: Lifecycle change moves automation, documentation, techniques, timing and roles — not fundamentals.

In sequential models (for example waterfall or the V-model) executable code is created in later phases, so early testing is static testing plus test analysis and design.

In the initial phases of a sequential model only documents exist. Testers therefore join requirement reviews and carry out test analysis and test design. The other options all need running software, either component builds, prototypes or sprint increments, none of which exist early in a sequential project.

1. Recall that a sequential model produces code only in later phases.
2. Rule out every activity that needs executable software.
3. Choose reviews, test analysis and test design.

Exam tip: Sequential model early phases: review and design tests; dynamic testing waits for code.

In a sequential SDLC, testers can perform static testing and test analysis and design early, but dynamic testing needs code that only appears in later phases.

Dynamic testing executes the software, and in a sequential model nothing is executable until the later phases. Static testing, test analysis and test design do not need running code, so they should start early. The distractors each delay one of those early activities, which contradicts the good practice of early testing.

1. Separate activities that need running code from those that do not.
2. Recall that sequential models produce code late.
3. Only dynamic testing must wait; choose that statement.

Exam tip: No code, no dynamic testing — but static testing and test design can start at once.

In iterative and incremental models, each iteration may deliver a working prototype or product increment, so both static and dynamic testing may be performed at all test levels in every iteration.

Because every iteration produces something that runs, the team can review it and execute tests on it at all test levels straight away. Frequent delivery also needs fast feedback and extensive regression testing. The distractors each push some dynamic testing or some test levels to the end, which is the pattern of a sequential model, not an iterative one.

1. Note that each iteration delivers working software.
2. Recall that working software allows dynamic testing at every level.
3. Reject options that defer testing to the end.
4. Choose static and dynamic testing at all levels per iteration.

Exam tip: Iterative model: every iteration gets static and dynamic testing at all levels, plus regression.

In Agile development change may occur throughout the project, so lightweight work product documentation and extensive test automation are preferred.

Agile teams expect requirements to change, which makes detailed up-front documents expensive to keep current and manual scripted regression too slow. They therefore keep documentation light and automate regression testing heavily. The distractors describe practices typical of sequential, document-driven models.

1. Recall that change can happen at any time in Agile.
2. Ask which practices cope best with frequent change.
3. Choose lightweight documentation with extensive automation.

Exam tip: Agile: light documentation, heavy automation.

In Agile, extensive test automation makes regression testing easier, and manual testing tends to use experience-based test techniques that do not require extensive prior test analysis and design.

Two facts must be combined. First, frequent releases and changing requirements make automated regression testing essential. Second, the manual testing that remains is usually experience-based, such as exploratory testing, because there is little time for detailed scripting. The first distractor gets the automation right but the manual approach wrong; the second gets the manual technique right but leaves regression manual.

1. Decide how regression is handled under two-week releases: automated.
2. Decide how manual testing is done when requirements change: experience-based.
3. Find the option that gets both halves right.
4. Reject options correct on only one half.

Exam tip: Agile: automate regression, explore manually.