EA / QA NOTES ← Back to notes

Test Process

SDLC

SDLC DEVELOPMENT MODELS

Six common development models and the key difference between them: how work is organized, delivered and

tested.

Model

Waterfall

Plan everything first, then build step by step.

Requirements → Design → Implementation → Testing → Deployment → Maintenance

Development happens in a predefined order. One phase is completed before moving to the next.

Best suited for: projects where requirements are stable and well understood.

Main weakness: users may not see working software until late, so incorrect

requirements can be expensive to discover.

Testing impact: test analysis and design can start early, but dynamic testing starts

when executable software is available.

Model

V-Model

Link every development activity with a corresponding test activity.

Requirements ↔ Acceptance Testing System Design ↔ System Testing Architecture ↔
Integration Testing Component Design ↔ Component Testing

Development and testing activities are planned in parallel, with test levels linked to development

work products.

Best suited for: projects with clear requirements and a strong need for

verification, validation and traceability.

Main weakness: the model is relatively rigid, and late changes can be costly.

Testing impact: test analysis and design start early, before the corresponding

executable software exists.

Model

Iterative

Build, test and improve through repeated cycles.

Plan → Design → Build → Test → Evaluate → Improve → Next Iteration

The solution is developed through repeated cycles. Each iteration revisits and improves what already

exists.

Best suited for: projects where requirements may evolve and feedback is needed

during development.

Main weakness: rework may be needed, and total effort can be harder to predict.

Testing impact: testing happens in every iteration, and regression testing becomes

increasingly important.

Model

Incremental

Deliver the product in small, usable parts.

Requirements → Increment 1 → Increment 2 → Increment 3 → …

Each increment adds new functionality to the existing product until the system becomes complete.

Best suited for: projects where early delivery of working functionality is

important.

Main weakness: integration becomes more complex and good architecture is essential.

Testing impact: each increment is tested together with existing functionality,

increasing the need for regression testing.

Model

Spiral

Focus on risk and refine the solution through cycles.

Planning → Risk Analysis → Engineering → Testing / Evaluation → Next Cycle

Development proceeds through repeated cycles driven by risk analysis and evaluation.

Best suited for: large, complex or high-risk projects.

Main weakness: it is complex and costly and requires strong risk-management

expertise.

Testing impact: testing and prototyping can be used early to reduce uncertainty and

evaluate risks.

Model

Agile

Adapt quickly and deliver in short cycles.

Plan → Design → Build → Test → Deliver → Feedback → Next Iteration

Development is iterative and incremental, with frequent delivery, collaboration and feedback.

Best suited for: projects where requirements change or are not fully known.

Main weakness: scope and estimates may change, and strong collaboration and

discipline are required.

Testing impact: testing is continuous throughout iterations, with strong emphasis on

fast feedback and regression testing.

Quick comparison

The Difference

| Model | Main idea | Pros | Cons | Testing impact |

| — | — | — | — | — |

Waterfall Sequential Simple, predictable Inflexible, testing starts late Dynamic testing later
V-Model Development ↔ Testing Early test planning, traceability Rigid, costly changes Testing planned from the start
Iterative Improve Early feedback, adapts over time Rework possible, harder to estimate Testing in every iteration
Incremental Add Early value, smaller deliveries Integration complexity Each increment tested + regression
Spiral Risk Strong risk management Complex, expensive Testing helps evaluate risks
Agile Adapt Flexible, fast feedback Scope and estimates may change Continuous testing

Test Analyst involvement

From Analysis to Execution

The Test Analyst is involved throughout the test process:

analyzing what needs to be tested, designing how it should be tested,

preparing testware for execution and evaluating the results.

The core flow

TEST ANALYSIS

What should we test?

→

TEST DESIGN

How should we test it?

→

TEST IMPLEMENTATION

Are we ready to execute?

→

TEST EXECUTION

Run, compare and evaluate.

Test Activity · 01

Test Analysis

What should we test?

During test analysis, the Test Analyst evaluates the

test basis to identify what needs to be tested.

The test basis is not limited to written documentation.

It may include requirements, user stories, specifications,

business processes, verbal information and other relevant

sources of knowledge.

Test basis

The Test Analyst evaluates the test basis for

completeness, consistency, correctness and testability.

Gaps, inconsistencies or changes may affect the test scope,

test conditions and planned testing.

Relevant test planning information should be available

before detailed test analysis proceeds.

Test scope + objectives + approach + test basis + product risks

→ Test analysis

The Test Analyst uses appropriate

test techniques

to identify test conditions.

These conditions are then prioritized based on the testing

objectives, product risks and other relevant factors.

Product risks are an important input.

Higher-risk areas normally require greater testing effort,

stronger coverage or higher priority.

Remember

Test analysis answers WHAT to test.

Test conditions are identified from the test basis

while considering objectives and product risks.

Test Activity · 02

Test Design

How should we test it?

During test design, the Test Analyst transforms

test conditions into test cases and other testware.

Test conditions → Test cases → Test data + Environment requirements

The way test design is performed and the required level of detail

depend on the project context.

Required coverage

Product risks

Test basis

SDLC

Test level

Tester knowledge & experience

Product complexity

Available time

Budget & tools

Depending on the context, the Test Analyst may design

high-level

or

low-level

test cases.

High-Level Test Case

Describes what should be tested without specifying

every concrete input or execution step.

Example

Verify that a registered user can reset

their password.

Low-Level Test Case

Provides concrete information such as preconditions,

inputs, actions and expected results so that the test

can be reproduced.

Example

Request a password reset for a registered account,

open a valid reset link, enter a valid new password

and verify that the old password is no longer accepted.

Level of detail

Experienced testers may work effectively with less detailed

test cases. More detailed testware may be needed when

reproducibility, traceability or support for less experienced

testers is important.

The Test Analyst also identifies the required

test data

and

test environment requirements.

Time, budget, available skills and tools may constrain

test design. The goal is not to create as many test cases

as possible, but to achieve appropriate coverage of the

objectives and risks.

Remember

Test design answers HOW to test.

Test conditions are transformed into test cases,

test data requirements and environment requirements.

Test Activity · 03

Test Implementation

Are we ready to execute?

During test implementation, the testware required for

execution is completed and organized.

Test cases → Test procedures → Test suites → Execution schedule

The Test Analyst contributes to ensuring that the required

testware, test data and test environment are ready

for test execution.

  other relevant factors.

  are available.

  test conditions and test cases where required.

Prioritization

Product risk is an important prioritization factor,

but it is not the only one. Dependencies, business priority,

test environment availability and other constraints may

also affect the execution order.

Remember

Test implementation prepares testing for execution.

Testware is finalized, organized and made ready to run.

Test Activity · 04

Test Execution

Execute, observe, compare and evaluate.

Tests are executed according to the planned

test execution schedule.

Execute → Observe → Compare → Analyze → Log → Report

During execution, the Test Analyst performs tests,

observes the actual results and compares them with

the expected results.

Test execution may include testing new functionality,

regression testing,

confirmation testing,

exploratory testing and the execution of predefined

test procedures.

Manual & automated testing

Tests may be executed manually or using automation.

The Test Analyst may identify suitable automation candidates

and provide domain and test-design knowledge, while automated

test implementation may involve technical testers,

automation engineers or developers.

Test execution is not only about following existing test cases.

The Test Analyst should also evaluate the information discovered

during testing.

  them manually when useful.

  and test design.

  test monitoring and control.

Remember

Execution produces new information.

Test results can reveal defects, new risks and coverage gaps

and may therefore lead back to test analysis and test design.

The Process Is Not Strictly Linear

Test analysis, test design, test implementation and test execution

may overlap and repeat. Information discovered during execution

can result in new test conditions, additional test cases,

changed priorities or newly identified risks.

New information / risk

→ Analysis

→ Design

→ Implementation

→ Execution

→ New information …

Content for this section can be added here later.