SE401 · Software Quality Assurance and Testing · Chapter 11

Every build step
has a mirror-image test step.

Draw the SDLC as a straight line, then fold it in half at Implementation — that fold is the V-model. Requirements mirror Acceptance test, design mirrors System test, detailed design mirrors Component test. This chapter is that mirror, plus what happens inside each reflection: which test level, which test type, and what still needs testing after the system ships.

3 life-cycle models

4 test levels

4 test types

Maintenance testing

§ 01 — SOFTWARE DEVELOPMENT MODELS

The life-cycle model decides how testing gets organized

Testing is highly related to development activities — so before you can talk about test levels, you need the shape of the development process they hang off of.

🪞

Memory hook

"Fold the waterfall in half and it becomes a V."

Waterfall is a straight cascade of phases ending in Testing. Fold that cascade at Implementation and mirror each phase with a matching test-execution phase — that fold is the V-model.

Waterfall model

User requirements → System requirements → Global design → Detailed design → Implementation → Testing

A strict cascade: each phase finishes before the next starts, and testing sits as one block at the very end.

The V-model

The same cascade, mirrored, with a test-preparation and test-execution stage for every development stage

Testing needs to begin as early as possible in the life cycle and can be integrated into each phase. Within the V-model, validation testing takes place especially during the early stages (reviewing the user requirements) and late in the life cycle (during user acceptance testing).

Iterative-incremental development

Define → Develop → Build → Test → Implement, repeated per phase

The process of establishing requirements, designing, building and testing a system carried out as a series of shorter development cycles. Each increment, added to what was built previously, forms a growing partial system — which should also be tested. Regression testing is increasingly important to all iteration phases after the first one.

§ 02 — WHAT TESTING IS FOCUSED ON

Verification vs. Validation

Two questions, asked at different moments, and constantly confused.

🔧

Memory hook

"veRification = Right way. vAlidation = right thing."

Verification: am I building the SW correctly? Validation: am I building the right SW?

Verification

correctly built

"Am I building the SW correctly?" — is the deliverable built according to the specifications?

Validation

right SW

"Am I building the right SW?" — is the deliverable fit for purpose, e.g. does it provide a solution to the problem?

§ 03 — TESTING WITHIN A LIFE CYCLE MODEL

Four traits of good testing, in any model

🔁

1 — Matching activity

Every development activity has a corresponding testing activity.

🎯

2 — Level-specific objectives

Each test level has test objectives specific to that level.

✍️

3 — Design starts early

The analysis & design of tests for a given test level should begin during the corresponding development activity.

👀

4 — Testers review drafts

Testers should be involved in reviewing documents as soon as drafts are available in the development life cycle.

Flexibility rule: test levels can be combined or reorganized depending on the nature of the project or the system architecture.

The V-model, level by level

Development stage	Test preparation	Test execution stage
User requirements	Preparation acceptance test	Acceptance test execution → operational system
System requirements	Preparation system test	System test execution
Global design	Preparation integration test	Integration test execution
Detailed design	—	Component test execution
Implementation	feeds directly into component test execution

Read the arrows: each dev stage on the left points across to its preparation stage, which points up to its execution stage — that's the literal shape of the "V". The higher up the V, the bigger the scope of both the requirement and the test.

§ 04 — TEST LEVELS

Four levels, stacked bottom to top

For each test level, the deck asks you to know: the generic objectives, the test basis (docs/products used to derive test cases), the test objects (what is being tested), typical defects/failures found, and specific approaches & responsibilities.

🏛️

Chunking acronym — bottom to top

"CISA" — Component → Integration → System → Acceptance

Picture stacked discs growing wider as you go up: black (Component, smallest — any module/program/object separately testable) → dark blue (Integration, interfaces between components + interactions with other systems) → light blue (System, the whole product as defined by project scope) → outline (Acceptance, widest — the customer's responsibility, goal is confidence in the system).

⚫

Component (Unit)

Any module, program, object separately testable.

🔵

Integration

Interfaces between components; interactions with other systems (OS, HW, …).

🔷

System

Behavior of the whole product as defined by the project scope.

⚪

Acceptance

Responsibility of the customer — goal is to gain confidence in the system.

§ 05 — LEVEL 1

Component testing

a.k.a. unit testing

Verifying the functioning of software items (modules, methods, objects, classes etc.) that are separately testable. Includes testing of functionality and specific non-functional characteristics, such as resource behavior (e.g. memory leaks), robustness testing, and structural testing (e.g. branch coverage).

Test basis

All materials applicable for the component under test: specification of the component, software design, the data model (e.g. class diagrams), and the code itself.

Approach & responsibility

Component testing usually involves the programmer who wrote the code. Defects are fixed as soon as they are found, without formal recording of incidents. TDD (test-driven development) — prepare and automate test cases before coding — is used in XP (extreme programming).

Stubs & drivers

Writing code to test the project code — stubs, drivers, and simulators may be used.

Stub Driver

Stub: code that replaces a called component in order to simulate its purpose (e.g. "hard-coded" data replacing data from a database).

Driver: code that replaces another software component in order to call the component under test.

Worked example (from the slides)

public void getLocationListTest()
{
    //Arrange
    VisitorRepositoryStub stub = new VisitorRepositoryStub();
    VisitorBLL bll = new VisitorBLL(stub);
    List<LocationSummary> expectedResult = stub.getLocationList("nb-NO");
    //Act
    List<LocationSummary> result = bll.getLocationList("nb-NO");
    //Assert
    Assert.Equal(expectedResult.Count(), result.Count());
    Assert.Equal(expectedResult[0].id, result[0].id);
}

Arrange–Act–Assert: a VisitorRepositoryStub stands in for the real database repository so VisitorBLL can be tested in isolation — exactly the stub definition above, made concrete.

§ 06 — LEVEL 2

Integration testing

interfaces between parts

Tests interfaces between components. Test interactions with different parts of a system, such as the operating system, file system, hardware, and interfaces between systems.

Two types

Component integration	Tests the interactions between software components — done after component testing.
System integration	Tests the interactions between different systems — done after system testing.

Test basis & test objects

Basis: software and system design, the system architecture, workflows/use cases. Objects: builds including some or all components of the system, database elements, system infrastructure, interfaces between components/objects, system configuration, configuration data.

Approach & responsibilities

Start integration with those components that are expected to cause the most problems.

Big bang vs. incremental (a past exam point): to reduce the risk of late defect discovery, integration should normally be incremental rather than "big bang."

Both functional and structural approaches may be used. Ideally, testers should understand the architecture and influence integration planning. Can be done by the developers or by a separate team.

§ 07 — LEVEL 3

System testing

the whole product

Testing the behavior of the whole system as defined by the scope of the project.

Test basis

System requirements specification (functional and non-functional), business processes, risk analysis, use cases, other high-level descriptions of system behavior and interactions with OS/system resources. Requirements may exist as text and/or models — and testers also need to deal with incomplete or undocumented requirements.

Test objects

The entire integrated system, user manuals, operation manuals, system configuration information, configuration data.

Approach & responsibilities

Test environment should correspond to the production environment as much as possible (e.g. same OS).

Ordering rule to memorize: first, the most suited black-box technique — then, white-box technique to assess the thoroughness of testing.

An independent test team may be responsible for the testing. The level of independence is based on the applicable risk level.

§ 08 — LEVEL 4

Acceptance testing

the customer's call

Answers three questions: can the system be released? What are the outstanding risks? Has development met its obligations? The goal is to establish confidence in the system and in its non-functional characteristics.

💉

Four types, memory hook

"User Operates, Contracts Approve"

User acceptance testing · Operational testing · Contract & regulation acceptance testing · Alpha/beta testing

Test basis

User requirements specification, use cases, system requirements specification, business processes, risk analysis.

Responsibilities

Customers or users of a system. Stakeholders may be involved.

User acceptance testing	Validates the fitness for use of the system by users.
Operational testing	Usually done by system administrators: backup/restore, disaster recovery, user management, maintenance tasks, periodic checks of security vulnerabilities.
Contract & regulation acceptance testing	Performed against a contract's acceptance criteria (e.g. governmental, legal, or safety regulations).
Alpha / beta testing	Alpha: performed at the developing organization's site. Beta (field testing): performed by people at their own locations. Both are performed by potential customers, not the developers of the product.

§ 09 — TEST TYPES

Four lenses you can point at any test level

Test levels are "where" in the SDLC you test. Test types are "what angle" you test from — and any of the four can be applied at any of the four levels.

🧭

Memory hook

"What it does, how it works, why it broke."

Functional = what the system does. Non-functional = how well it does it. Structural = how the code itself is built (coverage). Related to changes = did it still work after we touched it.

⚙️

Functional ("what")

Suitability, interoperability, security, accuracy, compliance.

📈

Non-functional ("how")

Performance/load/stress, reliability, usability, efficiency, maintainability, portability.

🧩

Structural

Measured via code coverage.

♻️

Related to changes

Confirmation testing and regression testing.

Functional testing (black-box)

external behavior

Objective: test what a system should do, considering the external behavior of the software. Test levels: may be performed at all test levels. Test basis: the expected behavior description can be found in work products such as requirements specification, business processes, use cases, functional specifications — may be undocumented.

Non-functional testing

quantified on a scale

Objective: measuring characteristics of software that can be quantified on a varying scale, e.g. response times for performance testing. May be performed at all test levels. Detailed in "Software Engineering — Software Product Quality" (ISO 9126).

Structural testing (white-box)

coverage

Objective: measuring the thoroughness of testing through assessment of the coverage of a set of structural elements or coverage items. May be performed at all test levels, but especially in component testing and component integration testing.

Test basis

Based on the structure of the code as well as the architecture of the system (e.g. a calling hierarchy, a business model, or a menu structure).

Approach & tools

Structural techniques are best used after specification-based techniques, to help measure the thoroughness of testing. Coverage measurement tools assess the percentage of executable elements (e.g. statements or decision outcomes) that have been exercised.

Testing related to changes

confirmation + regression

Objective: to verify that modifications in the software or the environment have not caused unintended side effects and that the system still meets its requirements. May be performed at all test levels, applies to functional, non-functional, and structural testing.

Confirmation testing

After a defect is detected and fixed, the software should be retested to confirm that the original defect has been successfully removed.

Regression testing

The repeated testing of an already tested program, after modification, to discover any defects introduced or uncovered as a result of the change(s).

The extent of regression testing is based on the risk of finding defects in software that was working previously. Regression test suites are run many times and generally evolve slowly, so regression testing is a strong candidate for automation. If the regression test suite is very large, it may be more appropriate to select a subset for execution.

§ 10 — QUALITY MODEL

ISO 9126 — the six characteristics non-functional testing measures

This is the reference model behind every "non-functional" bullet above — it's the answer key when an exam question just says "which quality characteristic is this?"

🎡

Memory hook

"FRU-PEM" wheel — Functionality, Reliability, Usability, Portability, Efficiency, Maintainability

Picture a six-spoke wheel around a hub labeled ISO 9126, plus Compliance sitting at the center alongside it.

Characteristic	Sub-characteristics (from the slide)
Functionality	Suitability, accuracy, security, interoperability
Reliability	Maturity, fault tolerance, recoverability
Usability	Learnability, understandability, attractiveness, operability
Efficiency	Resource utilisation, time behaviour
Maintainability	Analysability, changeability, testability, stability
Portability	Adaptability, replaceability, installability, co-existence
+ Compliance — sits alongside the six as its own dimension

§ 11 — AFTER RELEASE

Maintenance testing

Testing doesn't stop at acceptance — it continues for as long as the system is alive.

Maintenance testing

the operational system

Objective: maintenance testing is done on an existing operational system, and is triggered by modifications, migration, or retirement of the software or system.

💊

Memory hook

Think "MMR" — the vaccine shot, not test types

Modifications, Migration, Retirement — the three triggers for maintenance testing, given as a booster shot to keep an aging system healthy.

🛠️

Modifications

Planned enhancement changes (e.g. release-based); corrective and emergency changes (patches); changes of environment (OS or database upgrades).

🚚

Migration

e.g. from one platform to another — needs operational tests of the new environment plus tests on the changed software.

🗄️

Retirement of a system

Testing of data migration or archiving if long data-retention periods are required.

Scope

Related to the risk of the change, the size of the existing system, and the size of the change.

Test levels

Depending on the changes, maintenance testing may be done at any or all test levels and for any or all test types.

Approach

Determining how the existing system may be affected by changes is called impact analysis, and is used to help decide how much regression testing to do.

Note: maintenance testing can be difficult if specifications are out of date or missing.

§ 12 — CHEAT SHEET

Every test level, one table

Level	Objective	Test basis	Responsibility
Component	Verify software items separately testable (modules, methods, objects, classes)	Component spec, software design, data model, code	Usually the programmer who wrote the code
Integration	Test interfaces between components / interactions with other systems	Software & system design, architecture, workflows/use cases	Developers or a separate team; incremental, not big bang
System	Test the behavior of the whole system as defined by project scope	System requirements spec, business processes, risk analysis, use cases	Often an independent test team; black-box then white-box
Acceptance	Establish confidence to release the system	User requirements spec, use cases, business processes, risk analysis	Customers, users, stakeholders

Four test types, one table

Type	Answers	Levels
Functional (black-box)	What the system should do — external behavior	All levels
Non-functional	Quantifiable quality on a varying scale (ISO 9126)	All levels
Structural (white-box)	How thorough is the testing — code coverage	All levels, especially component & component integration
Related to changes	Did the fix work (confirmation), did it break something else (regression)	All levels; strong automation candidate

§ 13 — COMMON MISTAKES

Where students actually lose marks

These are the specific mix-ups this chapter invites — drill the ✓ RIGHT side until it's automatic.

1. Verification vs. Validation

✗ WRONG

"Verification checks if the software solves the problem."

✓ RIGHT

Verification checks if it was built correctly against the spec. Validation checks if it's the right solution/fit for purpose.

Why students mix it up: both sound like "does it work" — but one is about matching a spec, the other about matching a real-world need.

2. Confirmation testing vs. Regression testing

✗ WRONG

"They're the same thing — retesting after a fix."

✓ RIGHT

Confirmation testing retests the specific defect that was fixed. Regression testing retests everything else to catch unintended side effects.

A single bug fix needs both: confirm the bug is gone, then regress to check nothing else broke.

3. Component integration vs. System integration — the order

✗ WRONG

"System integration happens before system testing."

✓ RIGHT

Component integration is done after component testing. System integration is done after system testing.

Integration testing sits between two levels each time — it isn't a single stage, it's two separate stages named after what came right before them.

4. Alpha vs. Beta testing — who performs them

✗ WRONG

"Beta testing is done by the development team, in the field."

✓ RIGHT

Alpha: at the developing organization's site. Beta (field testing): at the users' own locations. Both are performed by potential customers, not the developers.

The variable is location, not who's doing the testing — the tester is a potential customer either way.

5. Big bang integration "saves time"

✗ WRONG

"Big bang integration is fine — it's faster to just plug everything in at once."

✓ RIGHT

To reduce the risk of late defect discovery, integration should normally be incremental rather than big bang.

This exact line was flagged as a past exam point on the slide — big bang doesn't fail more, it fails later and harder to localize.

6. Functional vs. Structural testing

✗ WRONG

"Structural testing checks what the system should do."

✓ RIGHT

Functional = what the system does (black-box, external behavior). Structural = how thoroughly the code was exercised (white-box, code coverage).

Structural testing doesn't ask "is the answer right," it asks "did our tests actually touch this branch of code."

7. Who does component testing

✗ WRONG

"A separate QA team always writes and runs component tests."

✓ RIGHT

Component testing usually involves the programmer who wrote the code, with defects fixed on the spot, without formal incident recording.

This flips at higher levels — system testing is more likely to involve an independent team; component testing is the most developer-owned level.

8. Black-box / white-box order in system testing

✗ WRONG

"Run white-box structural checks first, then confirm behavior with black-box tests."

✓ RIGHT

First the most suited black-box technique — then white-box technique to assess the thoroughness of that testing.

You can't measure "thoroughness of testing" (white-box's job) until testing has already happened (black-box's job) — coverage is measured against tests that already exist.

§ 14 — POP QUIZ

Click a question to reveal the answer

No reload, no scoring pressure — just click each card.

MCQ
In the V-model, "Preparation System test" mirrors which development stage?

System requirements. The V-model pairs System requirements → Preparation system test → System test execution — same horizontal level of the V.

Short answer
In one sentence, what's the difference between verification and validation?

Verification asks "am I building the SW correctly?" (matches the spec); validation asks "am I building the right SW?" (fit for purpose / solves the problem).

True / False
Beta testing is performed by the developers of the product.

False. Both alpha and beta testing are performed by potential customers, not the developers — alpha at the developer's site, beta at the customer's own location.

Short answer
Name the two types of integration testing and what each follows.

Component integration — done after component testing. System integration — done after system testing.

MCQ
In system testing, which technique is applied first?

Black-box. The most suited black-box technique goes first; white-box is used afterward to assess the thoroughness of that testing.

Short answer
What is "impact analysis" used for in maintenance testing?

Determining how the existing system may be affected by a change — used to help decide how much regression testing to do.

MCQ
Which test type category does "Usability" belong to?

Non-functional testing (ISO 9126) — usability breaks down into learnability, understandability, attractiveness, and operability.

Short answer
Name the three triggers for maintenance testing.

Modifications, Migration, Retirement (the "MMR" mnemonic) — of the software or the system.

§ 15 — PRACTICE LAB

Apply the concepts to scenarios

Grounded directly in the slide definitions — the kind of scenario an exam question rephrases with different nouns.

1. A tester confirms that a login screen matches the spec's field lengths and validation rules exactly. Later, a stakeholder asks whether the login screen actually solves the users' real complaint about slow sign-in. Which activity is which?

→ First is Verification, second is Validation

Why: matching the spec = "built correctly" (verification). Solving the real problem = "right SW" (validation).

2. Looking at the V-model, during which development phase should the team begin preparing the Integration test?

→ Global design

Why: the V-model pairs Global design with "Preparation Integration test," feeding into Integration test execution.

3. A component test replaces a database call with hard-coded location data so `VisitorBLL` can be tested without a live database connection. What is this piece of test code called?

→ A stub

Why: a stub is code that replaces a called component to simulate its purpose — exactly what "hard-coded data to replace data from a database" describes.

4. A team decides to plug in all 12 modules of a new system simultaneously the week before release, rather than a few at a time. What's the risk, and what's the recommended approach instead?

→ Big bang risks late defect discovery; incremental integration is recommended

Why: to reduce the risk of late defect discovery, integration should normally be incremental rather than "big bang" — flagged on the slide as a past exam point.

5. A project's regression test suite has grown so large it can no longer run before every release deadline. What does the slide recommend?

→ Select a subset of the regression suite for execution

Why: "if the regression test suite is very large it may be more appropriate to select a subset for execution" — based on the risk of finding defects in previously-working software.

6. A company migrates its inventory system from an on-premise server to the cloud. Per the maintenance testing slide, what two things need testing here?

→ Operational tests of the new environment, and tests on the changed software

Why: migration (e.g. from one platform to another) requires both — verifying the new environment works operationally, and verifying the software itself still behaves correctly on it.

Every build stephas a mirror-image test step.

The life-cycle model decides how testing gets organized

User requirements → System requirements → Global design → Detailed design → Implementation → Testing

The same cascade, mirrored, with a test-preparation and test-execution stage for every development stage

Define → Develop → Build → Test → Implement, repeated per phase

Verification vs. Validation

Verification

Validation

Four traits of good testing, in any model

1 — Matching activity

2 — Level-specific objectives

3 — Design starts early

4 — Testers review drafts

Four levels, stacked bottom to top

Component (Unit)

Integration

System

Acceptance

Component testing

Component testing

Integration testing

Integration testing

System testing

System testing

Acceptance testing

Acceptance testing

Four lenses you can point at any test level

Functional ("what")

Non-functional ("how")

Structural

Related to changes

Functional testing (black-box)

Non-functional testing

Structural testing (white-box)

Testing related to changes

ISO 9126 — the six characteristics non-functional testing measures

Maintenance testing

Maintenance testing

Modifications

Migration

Retirement of a system

Every test level, one table

Where students actually lose marks

1. Verification vs. Validation

2. Confirmation testing vs. Regression testing

3. Component integration vs. System integration — the order

4. Alpha vs. Beta testing — who performs them

5. Big bang integration "saves time"

6. Functional vs. Structural testing

7. Who does component testing

8. Black-box / white-box order in system testing

Click a question to reveal the answer

Apply the concepts to scenarios

Every build step
has a mirror-image test step.