Chapter 2 — Learning objectives
2.1 Testing in the Context of SDLC
FL-2.1.1K2Explain the impact of SDLC on testing
FL-2.1.2K1Recall good testing practices that apply independently of the chosen SDLC
FL-2.1.3K1Recall examples of test-first approaches (TDD, ATDD, BDD)
FL-2.1.4K2Summarize how DevOps might impact testing
FL-2.1.5K2Explain the shift-left approach
FL-2.1.6K2Explain how retrospectives can be used as a mechanism for process improvement
2.2 Test Levels and Test Types
FL-2.2.1K2Distinguish the different test levels
FL-2.2.2K2Distinguish the different test types
FL-2.2.3K2Distinguish confirmation testing from regression testing
2.3 Maintenance Testing
FL-2.3.1K2Summarize maintenance testing and its triggers
Chapter 2 at a glance
| Section | Core concept | Key exam focus |
|---|---|---|
| 2.1 | How SDLC model affects testing | Waterfall vs Agile differences, good practices, TDD/ATDD/BDD |
| 2.1.4 | DevOps & testing | Shift-left, CI/CD, benefits & challenges |
| 2.1.5 | Shift-left approach | What it means, how to achieve it |
| 2.1.6 | Retrospectives | When, who, benefits |
| 2.2.1 | 5 test levels | Which level tests what; who does it |
| 2.2.2 | 4 test types | Functional vs Non-functional; Black vs White box |
| 2.2.3 | Confirmation vs Regression | Was bug fixed? Did anything break? |
| 2.3 | Maintenance testing | Triggers, types, impact analysis |
2.1 Testing in the Context of SDLC
📌 What is SDLC?
SDLC (Software Development Lifecycle) is a high-level model describing the phases of software development and their sequence. The chosen SDLC model directly impacts how, when, and what testing is done.
🌍 Types of SDLC models
Sequential
Phases done one after another. Testing mostly at the end.
Examples: Waterfall V-Model
Iterative & Incremental
Development in cycles. Testing in each iteration.
Examples: Spiral Prototyping Unified Process
Agile & Modern
Continuous, flexible, light documentation, high automation.
Examples: Scrum XP Kanban Lean
⚙️ Impact of SDLC on testing — 6 areas
| SDLC affects | Explanation |
|---|---|
| Test scope & timing | Sequential: testing late; Agile: testing throughout each sprint |
| Test documentation level | Waterfall: heavy formal docs; Agile: lightweight documentation |
| Test techniques & approach | Formal techniques in sequential; exploratory & risk-based in Agile |
| Test automation level | Agile & DevOps require high automation; sequential may rely more on manual |
| Tester roles & responsibilities | Agile: shared quality ownership; Sequential: dedicated test phases with defined roles |
| Regression testing frequency | Agile: frequent due to continuous changes; Sequential: less frequent |
📊 Testing in different SDLC models
| Model | Testing timing | Static testing | Dynamic testing | Key characteristic |
|---|---|---|---|---|
| Sequential (Waterfall) | Late — after coding | Early (reviews, design) | Late (after build) | Testing phase distinct and separate |
| V-Model | Parallel to development | Yes — test design starts with requirements | Later phases | Each dev phase has corresponding test level |
| Iterative/Incremental | Each iteration | Yes | Yes — each iteration | Both static + dynamic at all levels |
| Agile | Continuous — every sprint | Yes | Yes — automated preferred | Light docs, high automation, frequent regression |
SDLC Models — Detailed Reference
Mnemonic: "A Big Dog X-rayed Five Kind Lions Sitting Together"
🏗️ The V-Model — key for ISTQB
| Development phase | ↔ | Test level |
|---|---|---|
| Requirements / Business analysis | ↔ | Acceptance Testing |
| System design | ↔ | System Testing |
| Architecture / High-level design | ↔ | Integration Testing |
| Detailed design / Coding | ↔ | Component (Unit) Testing |
V-Model principle: test design starts in the corresponding development phase, but test execution happens after coding. This supports early testing (shift-left).
🔧 Agile methodologies
Agile Framework
Scrum
Short sprints (1–4 weeks), roles: Scrum Master, Product Owner, Dev Team. Daily standups, Sprint reviews, Retrospectives.
Agile Method
XP (Extreme Programming)
Continuous feedback, pair programming, TDD, frequent releases, strong collaboration. Origin of Whole Team Approach.
Workflow
Kanban
Visualises tasks on a board. Limits Work In Progress (WIP). Pull-based flow. No fixed iteration length.
Philosophy
Lean
Removes waste, improves efficiency, delivers value faster. Minimise non-value-adding activities.
Design
DDD (Domain-Driven Design)
Software design based on the business domain and domain expert knowledge. Ubiquitous language shared across team.
Feature-based
FDD (Feature-Driven Dev)
Development organised around small client-valued features. Feature list → plan → design → build.
2.1.2 Good Testing Practices — independent of SDLC
✅ Four universal good practices
1
For every development activity → there is a corresponding test activity
All development activities are subject to quality control — testing is not a phase at the end, it runs in parallel.
2
Different test levels have specific and different test objectives
Allows testing to be comprehensive while avoiding redundancy — each level catches different defect types.
3
Test analysis and design begin during the corresponding development phase
Testing adheres to the early testing principle — test cases are being designed while requirements are still being written.
4
Testers review work products as soon as drafts are available
Supports shift-left — finding defects in requirements before any code is written is cheapest and fastest.
🔗 Connection to Chapter 1 principles
| Good practice | Links to principle |
|---|---|
| Test design starts in dev phase | Principle 3: Early testing saves time and money |
| Different objectives per level | Principle 2: Exhaustive testing is impossible — focus matters |
| Review work products early | Principle 3: Early testing + Shift-left (2.1.5) |
| Parallel dev & test activities | Principle 6: Testing is context dependent |
2.1.3 Test-First Approaches — TDD, ATDD, BDD
📌 Common characteristics
TDD, ATDD, and BDD are all test-first approaches — tests are defined before the code is written. They all implement the principle of early testing and follow shift-left.
- All support an iterative development model
- Tests may persist as automated tests for future regression after refactoring
- All improve code quality and reduce defects found later
🔴🟢🔵 TDD — Test-Driven Development
Directs coding through test cases instead of extensive upfront design. Tests are written first, then the minimum code to pass the tests, then both are refactored.
🔴 Write failing test
→
🟢 Write code to pass
→
🔵 Refactor
→
🔴 Repeat
Focus
Unit / component level. Developer-centric. Tests drive the design of the code.
Benefit
Forces simple design, catches regressions immediately, creates a living test suite.
📋 ATDD — Acceptance Test-Driven Development
Derives tests from acceptance criteria as part of the system design process. Acceptance tests are written before development to guide implementation.
Who is involved?
Business + Developers + Testers together (3 amigos). Tests express business requirements in executable form.
Process
1. Define acceptance criteria → 2. Write acceptance tests → 3. Develop feature to satisfy tests → 4. Run & verify
ATDD connection: directly links to section 4.5.3 (Acceptance Criteria and ATDD) — builds on Given/When/Then format.
📝 BDD — Behavior-Driven Development
Expresses the desired behavior of an application in simple natural language using the Given/When/Then format — easy for all stakeholders to understand.
Given the user is on the login page
When they enter valid credentials and click Login
Then they should be redirected to the home page
When they enter valid credentials and click Login
Then they should be redirected to the home page
Benefit
Bridges gap between business and technical. Scenarios become automated executable tests (e.g., Cucumber, JBehave).
Tools
Cucumber (Java/Ruby), JBehave, Behave (Python), SpecFlow (.NET)
⚡ TDD vs ATDD vs BDD — comparison
| Aspect | TDD | ATDD | BDD |
|---|---|---|---|
| Tests written by | Developer | Team (3 amigos) | Team + Business |
| Test level | Unit/component | Acceptance | Any (usually acceptance/system) |
| Language | Code (JUnit, etc.) | Acceptance criteria | Natural language (Given/When/Then) |
| Focus | Code correctness | Business requirements | System behavior |
| Tests defined | Before unit code | Before feature code | Before feature code |
| Tools | JUnit, NUnit, pytest | FitNesse, Concordion | Cucumber, JBehave |
All three: Tests written before code ✅ · Support iterative dev ✅ · Implement early testing principle ✅ · Follow shift-left ✅
2.1.4 DevOps and Testing
📌 What is DevOps?
DevOps is a collaborative approach that integrates development and operations using CI/CD, automation, and fast feedback to deliver high-quality software quickly and reliably.
Core focus areas
- Team collaboration & autonomy
- Fast feedback loops
- CI (Continuous Integration)
- CD (Continuous Delivery/Deployment)
- Automated delivery pipeline
CI vs CD
CI (Continuous Integration): Automatically build and test every code commit.
CD (Continuous Delivery): Automatically deploy to staging — human approval for production.
CD (Continuous Deployment): Fully automated production releases.
✅ Benefits of DevOps in testing
| Benefit | How it helps testing |
|---|---|
| Fast feedback on code quality | Tests run automatically on every commit — defects found within minutes |
| Supports Shift-Left testing | Tests integrated early in the pipeline — defects found before they reach production |
| Promotes automation | CI/CD requires automated regression, unit, and integration tests |
| Stable test environments | Containerisation (Docker) ensures test environments are consistent and reproducible |
| Non-functional visibility | Performance & reliability testing integrated into the pipeline |
| Reduced manual repetitive testing | Automation handles regression — testers focus on exploratory and new tests |
| Minimises regression risk | Every build is tested — regressions caught immediately |
⚠️ Challenges of DevOps for testing
- Requires significant pipeline setup and maintenance effort
- Need to manage and maintain CI/CD tools (Jenkins, GitHub Actions, etc.)
- Test automation is costly and complex to build and maintain
- Fast delivery pressure can compromise test coverage quality
Important: Even with high automation, manual testing (user perspective) is still important in DevOps — automation cannot replace human judgment and exploratory testing.
🔄 DevOps pipeline and testing touchpoints
Code commit
→
Build
→
Unit tests
→
Integration tests
→
Static analysis
→
Deploy to staging
→
Acceptance tests
→
Release
2.1.5 Shift-Left Approach
📌 What is Shift-Left?
Shift-left = performing testing activities earlier in the SDLC. Focus on detecting defects before or during coding rather than after. It does not eliminate later testing — it shifts focus earlier.
Requirements ← Test here early!
→
Design ← Test here too!
→
Coding
→
Testing
→
Release
Traditional testing only at the right end → Shift-left moves it to the left
🛠️ Practices to achieve shift-left
- Early review of requirements/specifications — find defects like ambiguity, gaps, contradictions before development
- Write test cases before coding — e.g., TDD, ATDD approach
- Use CI/CD — fast feedback and automated tests run on every commit
- Perform static testing before dynamic testing — catch code issues without running the software
- Start non-functional testing early — e.g., performance testing at component level, not just end-to-end
⚖️ Benefits vs Challenges
✅ Benefits
- Early defect detection
- Reduces cost and effort of fixing later
- Improves overall product quality
- Shorter feedback loops
- Aligns with early testing principle
⚠️ Challenges
- Requires extra effort and training early
- Needs strong stakeholder support
- Cultural change for teams used to late testing
- Testers must be involved from day one
Exam tip: Shift-left does NOT mean testing only early and skipping later stages. It means starting earlier and maintaining quality throughout.
2.1.6 Retrospectives and Process Improvement
📌 What is a retrospective?
A retrospective is a meeting held after a project, iteration, or release milestone where the team reflects on what went well, what went wrong, and how to improve.
👥 Who attends? & When?
Participants
- Testers
- Developers
- Business Analysts
- Product Owner
- Project Manager / Scrum Master
When held
- After project completion
- After each sprint/iteration
- After a release milestone
- After a test phase ends
💬 Discussion points (3 questions)
✅ What went well?
Identify practices to continue and build upon.
⚠️ What went wrong?
Identify problems to fix or avoid in future.
💡 How to improve?
Actionable steps to make things better next time.
Results are documented in the test completion report — lessons learned become inputs for future planning.
🎯 Benefits of retrospectives
| Area | Benefit |
|---|---|
| Test efficiency & effectiveness | Teams learn what worked and improve future test execution |
| Testware quality | Test cases, scripts, and plans are improved based on feedback |
| Team learning & bonding | Encourages knowledge sharing and mutual respect |
| Requirements quality | Issues in test basis (requirements) are flagged for improvement |
| Dev–test collaboration | Strengthens relationship between development and testing teams |
| Continuous improvement | Ensures lessons learned are actually applied — not lost |
2.2.1 Test Levels
📌 What are test levels?
Test levels = groups of test activities organised by development stage. In sequential models, exit criteria of one level become the entry criteria of the next.
Each test level differs by: test object · test objectives · test basis · defect types · approach & responsibilities
🏗️ Five test levels
Level 1
Component Testing (Unit Testing)
- Tests individual components in isolation
- Done by developers
- Uses test harness / frameworks (JUnit, NUnit)
- Test basis: detailed design, code
- Defects found: logic errors, code defects
Level 2
Component Integration Testing
- Tests interaction between components
- Done by developers or testers
- Strategies: Top-down, Bottom-up, Big-bang
- Test basis: software design, architecture
- Defects found: interface mismatches, integration failures
Level 3
System Testing
- Tests complete system behaviour
- Done by independent testers
- Functional (end-to-end) + Non-functional (performance, usability)
- Test basis: system requirements, use cases
- Defects found: system-wide failures, requirement gaps
Level 4
System Integration Testing
- Tests interaction with external systems/services/APIs
- Requires real-like environment
- Done by testers or specialists
- Test basis: system architecture, contracts/interfaces
- Defects found: integration failures, protocol mismatches
Level 5
Acceptance Testing
- Validates business requirements
- Done by users/customers/business
- Types: UAT, Operational Acceptance, Contractual, Regulatory, Alpha, Beta
- Test basis: business requirements, regulations
- Defects found: business needs not met
📊 Test levels — comparison table
| Level | Test object | Done by | Main objective |
|---|---|---|---|
| Component | Single module/function | Developer | Verify individual logic |
| Component Integration | Component interfaces | Developer/Tester | Verify component interactions |
| System | Complete system | Independent tester | Verify end-to-end behaviour |
| System Integration | External interfaces | Tester/Specialist | Verify external integrations |
| Acceptance | System vs business needs | User/Customer | Validate business requirements |
🤝 Acceptance testing sub-types
| Sub-type | Who does it? | Purpose |
|---|---|---|
| UAT | End users | Confirm system meets user needs in real-world scenario |
| Operational Acceptance | Ops team | Verify system is ready for production (backup, recovery, maintenance) |
| Contractual testing | Client/legal team | Verify system meets contractual requirements |
| Regulatory testing | Auditors/compliance | Verify compliance with laws, regulations, standards |
| Alpha testing | Internal team | Test product internally before external release |
| Beta testing | Real end users | Test product in real-world environment before final release |
2.2.2 Test Types
📌 What are test types?
Test types = groups of testing based on purpose and quality characteristics. Can be applied at any test level — only the focus changes.
1️⃣ Functional Testing
Tests what the system does — functional behaviour against requirements.
Functional completeness
Does the system provide all required functions?
Functional correctness
Does the system produce correct results?
Functional appropriateness
Are the functions suitable for the intended task?
Functional tests can be black-box (specification-based) or white-box (code-based).
2️⃣ Non-Functional Testing
Tests how well the system performs — quality characteristics beyond functionality (ISO/IEC 25010).
ISO 25010 quality characteristics
- Performance efficiency
- Compatibility
- Usability
- Reliability
- Security
- Maintainability
- Portability
- Safety
Key points
- Can start early in SDLC (e.g., performance at component level)
- Often derived from functional tests
- Sometimes needs special environments
- Late defects in non-functional = high project risk
- Performance testing tools: JMeter, Gatling, k6
3️⃣ Black-box Testing
Based on specifications — no knowledge of internal code structure. Focus on input → output behaviour.
- Validates system against requirements and business rules
- Techniques: Equivalence Partitioning, BVA, Decision Tables, State Transitions
- Can be done by independent testers without code access
- Good for finding requirement gaps and behaviour defects
4️⃣ White-box Testing
Based on internal code structure — requires knowledge of the code, logic, and flow.
- Focus: code coverage and structural testing
- Techniques: Statement coverage, Branch coverage, Path coverage
- Done by developers or testers with code access
- Finds unreachable code, logic errors, dead branches
⚡ All four types — quick comparison
| Type | Tests | Knowledge needed | Used at |
|---|---|---|---|
| Functional | What the system does | Requirements/specs | All levels |
| Non-functional | How well it performs | Quality characteristics | All levels |
| Black-box | Input → Output behaviour | No code knowledge | All levels |
| White-box | Internal code logic | Code structure | All levels |
Key exam point: All test types can be used at any test level. Functional and non-functional address what/how well; Black/White-box address knowledge of internals.
2.2.3 Confirmation Testing & Regression Testing
📌 Context — when are these performed?
Both types are performed after a defect fix or any change to the system.
✅ Confirmation Testing (Re-testing)
Verifies that the original defect has been successfully fixed.
How to perform
- Re-run the originally failed test cases
- Add new test cases if the fix requires new scenarios
- Sometimes limited to only the failed steps (due to time/cost)
Key point
Focuses only on the defect that was fixed. Does not check for side effects.
Question it answers: "Was the bug fixed?"
🔄 Regression Testing
Ensures that changes did NOT break existing functionality elsewhere in the system.
Scope of regression testing
- Same component that was changed
- Other components that interact with it
- Integrated systems
- Even the test environment itself
Key points
- Requires impact analysis to decide scope
- Test suite grows over time
- Best candidate for automation
- Common in CI/CD pipelines (DevOps)
- Performed at all test levels
Question it answers: "Did anything else break?"
⚡ Side-by-side comparison
| Aspect | Confirmation Testing | Regression Testing |
|---|---|---|
| Also called | Re-testing | — |
| Purpose | Verify the defect is fixed | Verify nothing else broke |
| Scope | Only the fixed defect area | Entire affected system |
| Tests used | Originally failed tests + new if needed | Existing regression suite |
| Automation? | Sometimes | Highly recommended |
| When? | After defect fix | After any change |
| Test levels | Relevant level | All levels |
| Key trigger | Bug closed/fixed | New code, patch, config change |
Exam tip: Confirmation and regression are often done together after a fix — first confirm the fix worked, then run regression to check for side effects.
2.3 Maintenance Testing
📌 What is maintenance testing?
Testing performed on a modified operational (live) system to ensure changes work correctly and no new defects are introduced into the existing functionality.
🔧 Types of maintenance
🐛 Corrective
Fix defects found in production. System is already live — urgent fixes needed.
e.g., Hot-fix for critical production bug
🔄 Adaptive
Adjust to environment changes — new OS, database upgrade, regulatory change.
e.g., Migrating to a new platform or OS version
✨ Perfective
Improve performance or maintainability without changing functionality.
e.g., Refactoring for better performance
🎯 Key activities in maintenance testing
Impact analysis
→
Plan test scope
→
Confirmation testing (check fix)
→
Regression testing (check side effects)
Impact analysis is critical before any maintenance testing — it identifies which parts of the system are affected by the change, determining the scope of testing needed.
📦 Scope depends on
Risk of change
High-risk changes require more thorough testing.
Size of system
Large complex systems need broader regression.
Size of modification
Small patch vs major refactor — scope differs greatly.
⚡ Triggers for maintenance testing
| Trigger category | Examples |
|---|---|
| Modifications | Bug fixes, enhancements, hot fixes, emergency patches |
| Upgrades | OS upgrade, database version change, browser update |
| Migration | Platform change, cloud migration, technology stack change |
| Environment change | New hardware, network configuration change, regulatory update |
| Data activities | Data migration, data archiving, data restore & retrieval testing |
| Retirement | Testing data archiving and retrieval when a system is decommissioned |
🔄 Maintenance testing vs normal testing
| Aspect | Normal (development) testing | Maintenance testing |
|---|---|---|
| System status | Under development | Already live/operational |
| Trigger | New development | Change to existing system |
| Priority | New features | Existing functionality first |
| Regression focus | New code | Existing + changed code |
| Impact analysis | Less critical | Critical — must be done first |
Keywords, exam traps & quick revision
📖 Key definitions
| Term | Definition |
|---|---|
| SDLC | Software Development Lifecycle — high-level model describing phases of development and their sequence |
| DevOps | Collaborative approach integrating dev and ops with CI/CD, automation, and fast feedback |
| Shift-left | Performing testing activities earlier in the SDLC to detect defects sooner |
| Retrospective | Meeting after a sprint/project to reflect on what went well, what went wrong, and how to improve |
| TDD | Test-Driven Development — write failing test → write code → refactor |
| ATDD | Acceptance Test-Driven Development — acceptance tests written before feature development based on acceptance criteria |
| BDD | Behavior-Driven Development — system behavior described in Given/When/Then natural language format |
| Test level | A group of test activities organised by development stage (component → acceptance) |
| Test type | A group of testing based on purpose and quality characteristics (functional, non-functional, etc.) |
| Functional testing | Tests what the system does — functional completeness, correctness, appropriateness |
| Non-functional testing | Tests how well the system performs — performance, security, usability, reliability, etc. |
| Black-box testing | Testing based on specifications only — no knowledge of internal code |
| White-box testing | Testing based on internal code structure — measures code coverage |
| Confirmation testing | Re-testing after a defect fix to verify the fix was successful |
| Regression testing | Testing after any change to ensure no existing functionality was broken |
| Maintenance testing | Testing performed on a modified live/operational system |
| Impact analysis | Identifying what parts of the system are affected by a change — determines regression scope |
| CI | Continuous Integration — automatically build and test every code commit |
| CD | Continuous Delivery/Deployment — automated deployment to staging/production |
🚨 Common exam traps
Trap 1: "Regression testing is only for fixing bugs" → FALSE — it's for any change (new feature, patch, config change)
Trap 2: "Confirmation testing checks side effects" → FALSE — that's regression testing. Confirmation only checks the fixed defect.
Trap 3: "Non-functional testing can only be done at system level" → FALSE — it can start early at component level
Trap 4: "Shift-left means skipping later testing" → FALSE — it shifts focus earlier but does NOT eliminate later testing
Trap 5: "DevOps eliminates the need for manual testing" → FALSE — manual testing (user perspective) is still important
Trap 6: "Test levels and test types are the same thing" → FALSE — levels = by stage; types = by purpose
Trap 7: "Retrospectives are only for Agile projects" → FALSE — they can be used in any SDLC after any milestone
Trap 8: "TDD, ATDD, BDD are the same" → FALSE — same principle (test-first) but different focus, level, and audience
Trap 9: "Acceptance testing is done by testers" → USUALLY FALSE — done by users/customers/business stakeholders
Trap 2: "Confirmation testing checks side effects" → FALSE — that's regression testing. Confirmation only checks the fixed defect.
Trap 3: "Non-functional testing can only be done at system level" → FALSE — it can start early at component level
Trap 4: "Shift-left means skipping later testing" → FALSE — it shifts focus earlier but does NOT eliminate later testing
Trap 5: "DevOps eliminates the need for manual testing" → FALSE — manual testing (user perspective) is still important
Trap 6: "Test levels and test types are the same thing" → FALSE — levels = by stage; types = by purpose
Trap 7: "Retrospectives are only for Agile projects" → FALSE — they can be used in any SDLC after any milestone
Trap 8: "TDD, ATDD, BDD are the same" → FALSE — same principle (test-first) but different focus, level, and audience
Trap 9: "Acceptance testing is done by testers" → USUALLY FALSE — done by users/customers/business stakeholders
⚡ Ultra-quick revision table
| Topic | One-liner |
|---|---|
| SDLC impact on testing | Affects scope, timing, docs, techniques, automation, roles |
| Good practices (4) | Parallel activities, different objectives per level, early design, review drafts early |
| TDD | Write test → write code → refactor · developer level |
| ATDD | Acceptance criteria → tests before development · 3 amigos |
| BDD | Given/When/Then natural language · all stakeholders understand |
| DevOps | CI/CD + automation + fast feedback — but still needs manual testing |
| Shift-left | Test earlier in SDLC — find defects before coding |
| Retrospective | After sprint/project — what went well/wrong/improve |
| Test levels (5) | Component → Component Integration → System → System Integration → Acceptance |
| Test types (4) | Functional · Non-functional · Black-box · White-box |
| Confirmation | Was the bug fixed? — re-test only the fixed area |
| Regression | Did anything else break? — entire affected system · automate |
| Maintenance | Testing on live systems — impact analysis first, then confirm + regress |