Testing Throughout the Software Development Life Cycle

2.1

Testing in the Context of a Software Development Cycle

A software development life cycle (SDLC) model is a high-level representation of the development process and the logical and temporal relationships among its activities. Testing must be integrated with the chosen SDLC. The model affects the scope and timing of testing, test levels and types, documentation detail, test techniques, practices, and automation.

2.1.1 Impact of the Software Development Life Cycle on Testing

Sequential Models

Development activities occur mainly one after another. Early testing is often static—such as requirement reviews and test design—because executable software arrives later.

Iterative Models

The product is refined through repeated cycles. Each iteration can revisit and improve previously produced functionality, enabling frequent feedback and repeated testing.

Incremental Models

The product grows by adding working pieces of functionality. Each increment contributes part of the final product and can be tested as it becomes available.

Agile Practices

Change is expected throughout development. Lightweight documentation, experience-based testing, rapid feedback, and extensive automation—especially regression automation—are common.

Waterfall Model

Requirements analysis, design, implementation, and testing proceed sequentially. Dynamic testing occurs relatively late, so defects discovered then can be expensive to correct. The approach is most suitable when requirements are stable and well understood.

V-Model

The V-model modifies the waterfall approach by integrating testing activities with development activities. Test levels correspond to development phases, promoting early test analysis, test design, and reviews even before executable software exists.

Unified Process (UP) Model

UP is iterative and incremental. Development disciplines such as requirements, design, implementation, testing, and deployment are selected and adapted to the project, with relatively substantial iterations and increments.

Boehm’s Spiral Model

The spiral model develops the product through repeated cycles and places particular emphasis on risk analysis before each successive development cycle.

Prototyping Model

Prototyping is useful when requirements or design goals are unclear. Rapid prototypes are evaluated by stakeholders, whose feedback helps refine the requirements.

Scrum

Scrum uses short, fixed-length iterations. Short cycles and frequent changes make rapid feedback, exploratory testing, and automated regression testing particularly important.

Kanban

Kanban visualizes work and controls flow using work-in-progress limits. It is a pull system: new work is taken when capacity becomes available.

Good testing practices across SDLCs

For every development activity there should be a corresponding test activity; different test levels should have specific objectives; test analysis and design should begin during the corresponding development activity; and testers should participate in reviewing work products as soon as drafts are available.

2.1.2 Software Development Life Cycle and Good Testing Practices

Whatever SDLC is selected, testing should start early, test activities should be aligned with development activities, and test objectives should be defined for the applicable levels. Early collaboration allows defects in requirements, architecture, design, and code to be found before they propagate.

2.1.3 Test-First Approaches to Development

Approach	Core idea	Typical focus
TDD — Test-Driven Development	Write a test before writing the code; implement enough code to pass; then refactor.	Code/component level
BDD — Behavior-Driven Development	Describe expected behavior using readable examples, commonly Given/When/Then; specifications can become executable “living documentation.”	Behavior shared by technical and business stakeholders
ATDD — Acceptance Test-Driven Development	Derive acceptance tests from acceptance criteria before implementation, collaboratively with developers, testers, and business representatives.	User/business acceptance

2.1.4 DevOps and Testing

DevOps brings development, testing, and operations closer together. Continuous integration and delivery pipelines can provide rapid feedback about code quality, run automated checks frequently, support repeatable environments, and make regression testing a regular part of delivery. Testing remains necessary; automation shifts where and how rapidly feedback is obtained.

2.1.5 Shift-Left Approach

Shift-left means performing testing and quality activities as early as possible in the SDLC. Examples include reviewing specifications before coding, continuous integration with automated component tests, static analysis, early nonfunctional testing, model-based testing, and test-first development such as TDD and ATDD.

Requirements→Design→Code→Deploy

Shift left: move reviews, analysis, test design, static analysis, automation and other quality activities toward earlier stages.

2.1.6 Retrospectives and Process Improvement

Retrospectives, or lessons-learned meetings, occur at milestones such as the end of an iteration, test level, or project. Participants discuss what worked, what did not, and how to improve. Topics can include processes, organization, people and skills, relationships, tools, and the product. Agreed improvement actions support continuous improvement and can feed into test completion reporting.

2.2

Test Levels and Test Types

A test level is an organized instance of the test process associated with a development stage. A test type groups test activities around particular objectives or characteristics. Levels and types are independent: a suitable test type can be performed at any test level.

2.2.1 Test Levels

Test level	Main focus	Typical perspective
Component testing	Individual modules, units, classes, methods, code and data structures	Usually developer-focused; detect component defects early
Component integration testing	Interfaces and interactions between components	Often developers; focus on communication, not already-tested component functionality
System testing	Behavior and capabilities of the integrated system as a whole	Often independent testers; verifies that the system was built right
System integration testing	Interfaces and interactions between systems and external services	Often testers; production-like environment is valuable
Acceptance testing	Business needs, readiness, and user confidence	User/customer perspective; validates that the right system was built

2.2.1.1 Component Testing

Also called unit or program testing, component testing targets separately testable modules. Objectives include reducing component risk, checking functional and nonfunctional behavior against specifications, building confidence, finding component defects, and preventing defects from escaping to higher levels. Typical bases include detailed design, code, data models, and component specifications.

2.2.1.2 Component Integration Testing and System Integration Testing

Integration testing focuses on interactions. Component integration testing examines interfaces between components; system integration testing examines interfaces between systems or external services. Incremental integration is preferable to “big bang” integration because failures can be localized more easily. Architecture-based top-down and bottom-up strategies may use stubs and drivers.

2.2.1.3 System Testing

System testing examines the complete integrated system. It evaluates functional and nonfunctional behavior, system completeness, overall correctness, risks, and quality. The test basis may include system requirements, risk reports, use cases, user stories, behavior models, state diagrams, and user manuals.

2.2.1.4 Acceptance Testing

Acceptance testing focuses on the system from the user or customer perspective. Its main purpose is validation and assessing readiness for deployment and use. Common forms include user acceptance testing (UAT), operational acceptance testing (OAT), contractual/legal acceptance testing, alpha testing, and beta testing.

UAT

Builds confidence that users can meet their needs and carry out business processes.

OAT

Focuses on operational readiness such as backup/recovery, installation, failure recovery, user management, maintenance, migration, security and performance.

Alpha

Customers, operators or independent testers test at the producer’s site.

Beta

Current or potential customers test in their own target environments.

2.2.2 Test Types

Test type	Question it answers	Basis
Functional testing	What should the system do?	Functional requirements, user stories, use cases, specifications
Nonfunctional testing	How well does the system behave?	Quality characteristics such as performance, usability, reliability, security, compatibility and portability
Black-box testing	Does externally visible behavior satisfy the specification?	Specification; internal implementation is not the basis
White-box testing	How thoroughly has the internal structure been exercised?	Code, architecture, control/data flow or other internal structure

2.2.2.1 Functional Testing

Functional testing evaluates functions the component or system should perform. It can be applied at every test level and often uses black-box techniques. Functional coverage can measure how much of a selected set of functional items, such as requirements, has been exercised.

2.2.2.2 Nonfunctional Testing

Nonfunctional testing evaluates characteristics describing how well the system performs rather than what functions it provides. Examples include performance efficiency, compatibility, usability, reliability, security, maintainability, and portability. It can and should be considered at multiple test levels.

2.2.2.3 Black-Box Testing

Black-box testing derives tests from specifications and externally visible behavior without using knowledge of the internal implementation as the basis for test design.

2.2.2.4 White-Box Testing

White-box testing derives tests from the internal structure of the test object. Coverage of code statements, decisions, paths, architecture, interfaces, or data flows can be used to evaluate thoroughness.

2.2.3 Confirmation Testing and Regression Testing

	Confirmation testing	Regression testing
Purpose	Confirm that a specific defect has been fixed.	Detect unintended adverse effects caused by a change.
Typical test	Re-run the test or steps that previously exposed the failure.	Re-run relevant previously passed tests around affected areas.
Planning	Exact executions usually cannot be scheduled in advance because defect discovery/fix timing is unknown.	Often scheduled and repeated regularly.
Automation	Possible, but depends on the failed test.	Strong automation candidate because it is frequent and repetitive.

2.3

Maintenance Testing

Maintenance testing is performed after software has been released and is in operational use. Changes are inevitable: defects are fixed, features evolve, environments change, security patches are applied, systems migrate, and eventually systems are retired. Testing before release is not maintenance testing.

Purpose

Verify that the maintenance change was implemented successfully and detect side effects in unchanged areas that may have been affected. Regression testing is therefore common, but migration, recovery, archiving, security, integration, and other tests may also be needed.

Maintenance Testing Triggers

Modification

Planned enhancements, corrective or emergency changes, environment upgrades, COTS updates, and security patches.

Upgrade or Migration

Moving to another platform or environment, including software changes and data conversion.

Retirement

Withdrawal of an application, potentially requiring migration, archiving, recovery testing, and regression testing for functionality that remains in use.

Impact Analysis

Impact analysis evaluates intended effects, potential side effects, affected system areas, and impacts on existing tests. It can be performed before a change to help decide whether the change should be made and to identify regression scope. It becomes difficult when specifications or tests are outdated, traceability is missing, tool support is weak, domain/system knowledge is unavailable, or maintainability received insufficient attention.

★

Interactive Explorer

✓

Key Takeaways

Exam focus

Distinguish sequential, iterative and incremental development; know TDD, BDD and ATDD; understand DevOps, shift-left and retrospectives; distinguish all five test levels and four principal test types; distinguish confirmation from regression testing; and know maintenance triggers and impact analysis.

Knowledge Check

Test your understanding with all 10 Chapter 2 sample questions. Choose one answer for each question.

Score: 0 / 10