Topic 1_ Testing Throughout the Software Life Cycle
TOPIC 2
TESTING THROUGHOUT THE SOFTWARE LIFE
CYCLE
1. Chapter Roadmap (The Big Picture)
Core Objectives: This chapter explores how testing fits into various software development lifecycle
(SDLC) models. It establishes the critical distinctions between test levels (where and when we test)
and test types (what we test). The core objective is to understand how to adapt testing strategies
to different development contexts and how to properly conduct both initial development testing and
post-release maintenance testing.
Learning Roadmap:
• Foundational Concepts: Software Development Models (Sequential vs. Iterative/Incremental)
→ Verification vs. Validation.
• Core Points: Test Levels (Component, Integration, System, Acceptance) → Test Types (Func-
tional, Non-functional, Structural, Change-related).
• Application/Extension: Maintenance Testing → Triggers and Impact Analysis.
2. Detailed Knowledge Synthesis (Combined Slides & Textbook)
2.1 2.1 Software Development Lifecycle Models (SDLC)
A software development lifecycle model describes the types of activity performed at each stage in a
software development project, and how the activities relate to one another logically and chronologically.
• Sequential Models (Waterfall & V-Model):
– Waterfall: A linear flow where testing tends to happen towards the end of the project life
cycle, meaning defects are detected close to the live deployment date.
– V-Model: Developed to address Waterfall’s late-testing problem by integrating testing into
each phase. It emphasizes early test design to find defects in the test basis documents
and stop fault multiplication. It demonstrates that for every development phase, there is a
corresponding test level (e.g., User Requirements match Acceptance Testing).
• Iterative & Incremental Models (Agile, Scrum, Kanban):
– Testing is continuous throughout development, with the software growing incrementally.
– Because features are constantly added, regression testing becomes increasingly important
on all iterations after the first one.
• Characteristics of Good Testing (in ANY life cycle model):
1. For every development activity, there is a corresponding testing activity.
2. Each test level has test objectives specific to that level.
3. Test analysis and design should begin during the corresponding development activity.
4. Testers should be involved in reviewing documents as soon as drafts are available.
• Verification vs. Validation:
Author: Vu Hong Quan | Why fade away when you can shine Page 1
Topic 1_ Testing Throughout the Software Life Cycle
– Verification: “Are we building the product right?” (Evaluating whether the product satis-
fies the specified requirements and conditions).
– Validation: “Are we building the right product?” (Evaluating whether the product meets
user needs and is fit for purpose).
2.2 2.2 Test Levels
Test levels are groups of test activities organized and managed together, each characterized by specific
objectives, test basis, test objects, and responsibilities.
• Component Testing (Unit/Module Testing):
– Objective: Verifies the functioning of software components that are separately testable.
– Approach: Tested in isolation using stubs and/or drivers. Usually performed by the devel-
oper.
– TDD (Test-Driven Development): A highly iterative approach where automated test cases
are prepared before coding.
• Integration Testing:
– Objective: Tests interfaces between components, interactions to different parts of a system,
or interfaces between systems.
– Two variations: Component Integration Testing (interactions between software compo-
nents) and System Integration Testing (interactions between different systems or microser-
vices).
– Approaches:
∗ Top-down: Needs Stubs to simulate missing lower-level components.
∗ Bottom-up: Needs Drivers (test harnesses) to call the baseline configuration.
∗ Big-bang: Combining everything at once. Takes longer to locate and fix faults.
• System Testing:
– Objective: Verifies the behavior of the whole system/product against specified requirements.
– Approach: Conducted by an independent test team. The test environment should ideally
correspond to the final production environment to minimize environment-specific failures.
• Acceptance Testing:
– Objective: Validation testing to determine whether the system is fit for purpose and satisfies
user needs.
– Types of Acceptance Testing:
∗ UAT (User Acceptance Testing): Done by end-users to build confidence in business
processes.
∗ OAT (Operational Acceptance Testing): Done by system administrators focusing on
backups, disaster recovery, user management, and security.
∗ Contract & Regulation Testing: Testing against strict contractual terms or govern-
ment/legal regulations.
∗ Alpha & Beta Testing: Alpha is performed at the developer’s site by people outside
the dev organization. Beta (field testing) is performed at an external customer site by
diverse users.
Author: Vu Hong Quan | Why fade away when you can shine Page 2
Topic 1_ Testing Throughout the Software Life Cycle
2.3 2.3 Test Types (The Targets of Testing)
• Functional Testing (“What” the system does): Evaluates compliance with functional
requirements. Derived from business requirements, use cases, or business processes.
• Non-functional Testing (“How well” the system does it): Tests quality characteristics
such as performance, load, stress, usability, maintainability, and reliability. These can be mea-
sured on a scale.
• Structural (White-box) Testing (“Inside the box”): Measures the thoroughness of testing
through the coverage of a set of structural elements (e.g., code statements, branches, architec-
ture).
• Change-related Testing:
– Confirmation Testing (Re-testing): Executing tests that previously failed to confirm that
the specific defect has been fixed.
– Regression Testing: Executing tests in unchanged areas of the software to ensure that the
defect fix (or any new change) did not introduce unintended side effects.
2.4 2.4 Maintenance Testing
Executed on an existing operational system during its life cycle.
• Triggers:
– Modifications: Planned enhancements, corrective changes, or environment upgrades (e.g.,
OS patches).
– Migration: Moving from one platform to another.
– Retirement: Data archiving and data retention when a system is decommissioned.
• Impact Analysis: The critical process of determining what areas of the system could be affected
by a change, helping to define the necessary scope of regression testing.
3. Traps, Common Mistakes & Blind Spots
Keywords for Concept Recognition:
• Verification: Build the product right / Specifications.
• Validation: Build the right product / User needs / Fit for purpose.
• Stub: Simulates missing called (lower-level) components.
• Driver: Simulates missing calling (upper-level) components.
• Alpha Testing: Done at the developer’s site.
• Beta Testing: Done at the customer’s site.
Easily Confused Concepts:
• Confirmation Testing vs. Regression Testing: Confirmation testing checks the exact defect
that was fixed. Regression testing checks the surrounding, unchanged code to ensure nothing
else broke.
• Component Integration vs. System Integration: Component integration tests interfaces
between modules within the same application. System integration tests interfaces between en-
tirely different systems or external microservices.
Author: Vu Hong Quan | Why fade away when you can shine Page 3
Topic 1_ Testing Throughout the Software Life Cycle
Exam Traps (Tricks):
• Trap: “Non-functional testing (like performance testing) can only be performed during System
Testing.” → FALSE. Functional, non-functional, and structural testing can occur at any test
level (e.g., You can test the performance of a single API component).
• Trap: “Acceptance testing’s main goal is to find as many defects as possible.” → FALSE. The
main goal is to establish confidence that the system satisfies business needs. Finding defects is
the primary goal of System testing.
• Trap: “Big-bang integration is the fastest and most efficient integration strategy.” → FALSE.
Big-bang combines everything at once, making fault isolation extremely difficult and time-
consuming.
Edge Cases & Exceptions:
• Maintenance testing without specifications: In legacy systems where documentation is
poor or missing, testers cannot strictly verify the system. They must use exploratory testing
and consult current users to establish a baseline for regression tests.
4. Memory Tips & Approaches (Tips & Hacks)
• The “V” Match-Up Hack: To remember which test level corresponds to which development
phase in the V-Model, visualize the V:
– User Requirements ↔ Acceptance Testing
– System Specifications ↔ System Testing
– Global/Architecture Design ↔ Integration Testing
– Detailed Design ↔ Component Testing
• Stubs vs. Drivers Logic:
– Stubs = Substitute for Subordinates (used in Top-down integration).
– Drivers = Drive the application from above (used in Bottom-up integration).
• The 4 Test Types Acronym (FNSC): Memorize “Fun Night Studying Code” to recall the
four test types:
– Functional (What)
– Non-functional (How well)
– Structural (Internal)
– Change-related (Re-test & Regression)
• Alpha/Beta Location Logic: Alpha starts at At home (Developer site). Beta goes Beyond
(Customer site).
Author: Vu Hong Quan | Why fade away when you can shine Page 4