ISTQB Foundation Level Chapter 2: Testing Throughout the Software Development Lifecycle

What this chapter covers

Testing in the context of a software development lifecycle

The syllabus opens by explaining that testing does not exist on its own. It has to fit around whatever development approach a team is using. You need to be able to recognize how the SDLC model in use affects test activities (a K2-level objective), since the same test process from Chapter 1 gets applied differently depending on context.

A sequential model like the V-model maps each development phase to a corresponding test level, so component testing lines up with coding, integration testing with the integration phase, and so on. Iterative and incremental models, including most Agile approaches, repeat the test activities for each iteration, with testing happening continuously rather than in one block at the end.

Good testing practices that apply across SDLC models include things like having a representative of the test team involved in requirements and design reviews, defining clear entry and exit criteria for each test level, and writing testable requirements and user stories from the start. The syllabus also expects you to be able to recognize good testing practices specific to iterative development, such as having tests written for every backlog item before development on that item begins, and continuously integrating and testing software as it is developed.

Test-first approaches are also part of this section. Test-driven development (TDD), acceptance test-driven development (ATDD), and behavior-driven development (BDD) all share the idea of defining tests before the code that will satisfy them is written. This is a form of early testing (testing principle 3 from Chapter 1) and an example of shift left, which we'll come back to shortly.

DevOps gets its own learning objective at K1, meaning you should be able to recall what it is. DevOps is an organizational approach where development, operations, and often testing work together toward shared goals, with an emphasis on automation, continuous delivery, and fast feedback. Continuous integration, continuous delivery, and continuous deployment are all practices associated with DevOps that depend heavily on automated testing.

Shift left is the practice of moving testing activities as early as possible in the SDLC, rather than waiting until the end. Reviews of requirements, early static analysis of code, and test-first approaches are all examples of shift left in action. The idea connects directly back to testing principle 3 (early testing saves time and money) from Chapter 1.

Finally, the syllabus covers retrospectives. A retrospective is a workshop held at the end of a project, release, sprint, or iteration where the team reflects on what went well, what did not, and what could be improved. Testers can use retrospectives to raise issues found during testing and to suggest process improvements, which ties into the test completion activities covered in Chapter 1.

Test levels and test types

This section is one of the most heavily tested parts of the entire syllabus, and it is where a lot of candidates get confused because the five test levels and four test types describe two different ways of slicing up testing work.

Test levels are groups of test activities that are organized and managed together, and each one is an instance of the full test process from Chapter 1 (planning, analysis, design, implementation, execution, and completion), applied to software at a particular stage. The five test levels are:

• Component testing (sometimes called unit testing): tests individual software components, often by developers, in isolation from the rest of the system.
• Integration testing: tests the interfaces and interactions between integrated components or systems. This can happen at the component integration level (between components within a system) or the system integration level (between different systems).
• System testing: focuses on the overall behavior of a complete system, often testing end-to-end functional and non-functional characteristics.
• System integration testing: focuses on testing the interfaces of a system with other systems or external services.
• Acceptance testing: typically the final level before a system is handed over to users or customers, and often focuses on whether the system meets business and user needs, including forms like user acceptance testing, operational acceptance testing, contractual and regulatory acceptance testing, and alpha and beta testing.

In sequential models, test levels often line up neatly with development phases, but in iterative models, multiple test levels can overlap or run in parallel, and development activities can span across what would traditionally be separate levels.

Test types, on the other hand, are groups of test activities related to a specific quality characteristic, and most test types can be applied at any test level. The four test types are:

• Functional testing: evaluates what the system does, checking functions against requirements, specifications, or expected behavior.
• Non-functional testing: evaluates characteristics like performance, usability, reliability, security, compatibility, and portability. The syllabus references ISO/IEC 25010 as a model for these quality characteristics.
• White-box testing: evaluates the internal structure of a component or system, such as code coverage of statements or branches (covered in more depth in Chapter 4).
• Change-related testing: covers confirmation testing and regression testing, which we look at next.

The key distinction to hold onto is that a test level describes when and at what scope testing happens, while a test type describes what kind of thing you're checking. A single test level, like system testing, can include functional tests, non-functional tests, and so on.

Confirmation testing and regression testing

This subsection builds directly on the debugging discussion from Chapter 1.

Confirmation testing (sometimes called re-testing) is performed after a defect has been fixed, to confirm that the original defect has actually been resolved. This typically means re-running the test case that originally failed, using the same inputs and conditions, ideally by the same person who ran the original test.

Regression testing involves re-running tests on a part of the software that has not been changed, to check that previously working functionality has not been broken by changes made elsewhere, such as the fix that triggered the confirmation test, a new feature, or even a change to the test environment.

Regression test suites tend to grow over time as a system evolves, which makes them good candidates for automation, since the same tests are likely to be run repeatedly. This connects back to testing principle 5 from Chapter 1 (tests wear out), since regression suites need ongoing maintenance to stay effective.

Maintenance testing

The final section of Chapter 2 covers what happens to testing once a system is in production. Maintenance testing is triggered by modifications, migrations, or retirement of a system.

• Modifications include planned enhancements, corrective changes (fixing defects), and adaptive changes (such as updates needed when the operating environment changes, for example a new operating system version).
• Migration testing checks that data and the system work correctly in a new environment, including testing the migrated data itself as well as the tools used to perform the migration.
• Retirement testing covers things like testing data archiving and migration when a system is decommissioned.

The amount and type of maintenance testing performed depends on factors like the risk of the change, the size of the existing system, and how long the system has been in operation. Impact analysis is used to help decide how much regression testing is needed in response to a given change, by identifying which parts of the system could be affected.

Chapter 2 at a glance