Session 4.3 - Functional Testing Design

What Is Functional Testing?

Functional testing is a type of black-box testing that validates the software against its stated functional requirements. It verifies that each function of the application behaves as specified — without looking at the internal code structure.

Focus
What the system does: inputs, processing, outputs, and the business rules that govern them.

Basis
Requirements specifications, user stories, use cases, functional design documents, and regulations.

Perspective
Mimics the end-user or business stakeholder perspective without knowledge of how code is written.

ISTQB Definition: Functional testing considers the external behaviour of the software. Tests are derived from the specification of what the component or system should do. The internal structure (code, architecture) is not considered.

Functional testing can be applied at all test levels — unit, integration, system, and acceptance — but is most prominent at the system testing level where full end-to-end behaviour can be observed.

System Testing Context

System testing is the test level at which the complete integrated system is tested to evaluate whether it complies with specified requirements. Functional testing is the primary activity within system testing.

Where system testing fits in the V-Model:

Development Phase	Corresponding Test Level	Primary Focus
Requirements Analysis	Acceptance Testing	Business / user needs
System Design	System Testing	Functional & non-functional
Architectural Design	Integration Testing	Interfaces between modules
Module Design & Coding	Unit Testing	Individual code units

System Testing goals

Verify all functional requirements are implemented correctly.
Confirm end-to-end data flows and business workflows.
Detect interface defects between subsystems.
Validate configuration and environment behaviour.
Identify regression issues after integration.

Who performs it?

Independent test team (preferred).
QA engineers using formal test plans.
Performed in a representative test environment.
Based on system specifications, not code.

ISTQB Objectives of Functional Testing

According to the ISTQB Foundation Level Syllabus, functional testing has the following key objectives:

1. Reduce Risk — Functional tests expose deviations from the specification before deployment, reducing the risk of failures in production.

2. Verify Behaviour Against Requirements — Confirm the system does exactly what the requirements state it should do — no more, no less.

3. Provide Stakeholder Confidence — Systematic, traceable test results give project sponsors and product owners confidence in delivery quality.

4. Find Missing or Misunderstood Requirements — Designing functional tests often reveals ambiguous, contradictory, or incomplete requirements early.

5. Support Decision-Making — Test results feed go/no-go decisions for release. Incomplete functional coverage is a risk signal.

Key ISTQB Principle relevant here — Principle 3: Early Testing
Designing functional test cases as soon as requirements are baselined is far cheaper than finding the same defects after deployment. Functional test design is a form of requirements review.

Test Basis & Sources

The test basis is any documentation from which test cases can be derived. For functional testing at system level, typical sources include:

Software Requirements Specification (SRS)
The primary source. Each functional requirement (FR) should map to at least one test case.

Use Cases & User Stories
Describe actor-system interactions. Each scenario (main, alternate, exception) becomes a test path.

Business Rules
Constraints and policies (e.g., discount logic, eligibility rules) that govern processing.

Prototypes & Mock-ups
UI prototypes reveal expected field behaviour, navigation flows, and validation messages.

Process / Data Flow Diagrams
Show data transformations and decision points that require functional verification.

Previous Defect Reports
Historical bugs highlight high-risk functional areas worth additional coverage.

What if the test basis is poor?
Ambiguous or incomplete requirements make functional testing harder and riskier. A tester's first action is to review the test basis and raise queries before designing tests. This is itself a quality activity aligned with ISTQB's emphasis on early testing.

Test Scenario Design

A test scenario is a high-level description of a test goal derived from a requirement or use case. It answers: "What aspect of functionality are we verifying?" Test cases are then the specific, executable steps within that scenario.

Scenario Design Process (step by step)

Read each functional requirement or user story carefully.
Identify the happy path (normal, successful flow).
Identify alternate paths (valid variations of the main flow).
Identify exception/error paths (invalid inputs, system constraints).
Identify boundary conditions and business rule transitions.
Write a one-line scenario title for each path identified.
Map each scenario to the requirement ID for traceability.

Example Requirement (FR-012): A registered user may place an order only if the item is in stock and the user's account balance is sufficient. On success, inventory is decremented and an order confirmation email is sent.

Derived Scenarios:

Scenario ID	Description	Type
SC-012-01	Place order: item in stock, sufficient balance	Positive / Happy Path
SC-012-02	Place order: item out of stock	Negative
SC-012-03	Place order: insufficient account balance	Negative
SC-012-04	Place order: both out-of-stock and insufficient balance	Negative (combined)
SC-012-05	Verify inventory decrements after successful order	Functional side-effect
SC-012-06	Verify confirmation email is sent on success	Integration / output

Positive & Negative Testing

Functional test design must deliberately include both positive and negative scenarios. Testing only the happy path is one of the most common gaps in functional test suites.

Positive Testing

Verifies the system works correctly for valid, expected inputs and conditions.

Valid data within allowed ranges
All mandatory fields populated correctly
Authorized user performs permitted action
Correct sequence of steps followed

Negative Testing

Verifies the system handles invalid inputs and error conditions gracefully.

Missing mandatory fields
Data outside allowed ranges
Unauthorized user attempts restricted action
Wrong sequence of steps (e.g., skip payment)

Edge Case Testing

Tests at the boundary between valid and invalid; at system limits; and under unusual but legal combinations.

Exactly minimum and maximum allowed values
Empty string vs. single-character input
Concurrent user actions on the same record
Business rule transitions (e.g., order total exactly equals account balance)

Rule of thumb: For every positive test scenario, design at least one corresponding negative scenario. This ratio ensures that both the acceptance and rejection logic of the system are verified.

Functional Coverage

Functional coverage measures what percentage of the defined functional requirements have been exercised by the test suite. Unlike code coverage (structural), functional coverage is requirement-driven.

Functional Coverage Formula:

Functional Coverage (%) = (Number of Requirements Tested / Total Number of Requirements) × 100

Requirement Coverage
Every FR must map to at least one test case. Uncovered requirements are untested functionality.

Scenario Coverage
All identified scenarios (positive, negative, edge) within a requirement should be executed.

Decision/Branch Coverage
In functional testing, every decision point in the business rule logic should be exercised at least once.

Coverage gaps are risk signals. A functional requirement with zero associated test cases means the system could fail on that requirement and testing would not detect it. Traceability matrices are the primary tool for tracking and closing coverage gaps.

ISTQB note: 100% requirement coverage does not guarantee the absence of defects — it only guarantees that each stated requirement has been tested. Unstated requirements (missing functionality) remain invisible to coverage metrics.

Test Case Specification

A test case is a set of inputs, execution preconditions, expected results, and postconditions developed for a particular objective. Functional test cases must be precise, repeatable, and traceable.

Standard Functional Test Case Structure

Field	Description	Example
Test Case ID	Unique identifier	TC-012-01
Test Case Title	Brief description of what is being verified	Place order with valid data
Requirement ID	The requirement(s) being covered	FR-012
Preconditions	System state required before test execution	User logged in; item in stock (qty≥1); balance ≥ item price
Test Steps	Numbered sequence of actions	1. Navigate to product page. 2. Click "Buy Now". 3. Confirm order.
Test Data	Specific values to use	Item: SKU-4421, Qty: 1, Balance: £50.00, Price: £29.99
Expected Result	What the system should do/display	Order confirmation page shown; inventory decremented; email sent
Actual Result	Recorded during execution	(Filled after execution)
Pass / Fail	Outcome based on expected vs actual	Pass / Fail / Blocked
Postconditions	System state after execution	Order appears in order history; stock qty reduced by 1

Quality checklist for a good functional test case:

Can it be executed by someone who did not write it?
Is the expected result unambiguous and measurable?
Is it traceable to at least one requirement?
Are preconditions achievable in the test environment?
Is the test data realistic and reproducible?

Requirement Traceability

A Requirements Traceability Matrix (RTM) maps each requirement to the test cases that verify it. It is essential for demonstrating that all requirements have been tested and for impact analysis when requirements change.

Sample RTM (partial)

Requirement ID	Requirement Description	Test Cases	Status
FR-010	User registration with email verification	TC-010-01, TC-010-02, TC-010-03	Covered
FR-011	User login with valid credentials	TC-011-01, TC-011-02	Covered
FR-012	Place order with stock and balance check	TC-012-01 … TC-012-06	Covered
FR-015	Apply promotional discount code	—	Not Covered

RTM uses:

Forward traceability: Requirement → Test Case (ensures coverage of requirements).
Backward traceability: Test Case → Requirement (ensures no orphan tests without a requirement).
Impact analysis: When a requirement changes, the RTM immediately shows which test cases need updating.

Worked Example: Library Book Reservation System

Requirement FR-024: A library member may reserve an available book online. If the book is already reserved by another member, the system shall add the requesting member to a waiting list (max 5 members). If the waiting list is full, the reservation shall be rejected with an error message.

Step 1: Identify scenarios

SC-01: Reserve available book (positive)
SC-02: Reserve book already reserved — join waiting list (positive alternate)
SC-03: Reserve book with full waiting list (negative)
SC-04: Reserve book — waiting list at exactly 5 members (boundary)
SC-05: Non-member attempts reservation (negative)

Step 2: Test cases (selected)

TC ID	Precondition	Input Action	Expected Result	Type
TC-024-01	Book available; user is a valid member	Reserve "Clean Code"	Reservation confirmed; book status = Reserved	Positive
TC-024-02	Book already reserved; waiting list has 2 members	Reserve "Clean Code"	Added to waiting list; position 3 shown	Positive (alternate)
TC-024-03	Book reserved; waiting list has exactly 5 members	Reserve "Clean Code"	Error: "Waiting list is full. Reservation rejected."	Negative / Boundary
TC-024-04	Book reserved; waiting list has 4 members	Reserve "Clean Code"	Added as 5th member; waiting list now full	Boundary (max-1)
TC-024-05	User not logged in	Attempt to reserve	Redirect to login page; no reservation created	Negative

Step 3: Traceability check
FR-024 → TC-024-01, TC-024-02, TC-024-03, TC-024-04, TC-024-05. All three conditions stated in the requirement (available, waiting list, full list) are covered. Coverage: 100% for this requirement.

Typical Defects Found by Functional Testing

Missing functionality
A required feature was never implemented. Often caught by checking the RTM for uncovered requirements.

Incorrect calculation or logic
Business rule implemented with wrong formula, wrong operator, or wrong condition (e.g., > instead of ≥).

Wrong or missing validation
System accepts data it should reject, or rejects data it should accept.

Incorrect data displayed
System stores the correct value but displays or formats it incorrectly to the user.

State management errors
System transitions to incorrect state (e.g., order status shows "Shipped" before payment is confirmed).

Integration failures
Data passed between modules is transformed incorrectly, causing downstream functional errors.

Common Mistakes in Functional Test Design

Only testing the happy path
Negative scenarios expose rejection logic defects that positive tests will never find.

Vague expected results
"System should work correctly" is not an expected result. Specify the exact message, value, or state change.

No traceability
Without mapping tests to requirements, coverage gaps are invisible and impact analysis is impossible.

Untestable preconditions
If the test environment cannot reach the required precondition, the test cannot be executed reliably.

Confusing scenario with test case
A scenario is a goal; a test case is the specific, executable procedure. Mix them up and tests become unrepeatable.

Ignoring postconditions
Failing to verify side effects (e.g., database updates, emails sent) leaves partial defects undetected.

Class Activity

Scenario: You are testing an online food ordering system. The requirement states: "A user may place an order for a minimum of 1 item and a maximum of 10 items of the same dish per transaction. Orders can only be placed between 10:00 AM and 10:00 PM."

Tasks (in pairs):

Identify at least 6 test scenarios (positive, negative, boundary, time-based).
Write 3 complete test cases in the standard format (ID, precondition, steps, data, expected result, postcondition).
Create a mini RTM mapping each test case to the requirement.
Identify 2 postconditions that should be verified after a successful order.

Evaluation Rubric (10 marks)

2 marks: At least one positive, one negative, and one boundary scenario correctly identified.
3 marks: Test cases are complete, unambiguous, and executable.
2 marks: RTM correctly maps each test case to the requirement.
3 marks: Expected results are precise and postconditions are meaningful.

Exit Ticket

Name three sources that can be used as the test basis for functional testing at system level.
A requirement states: "The system shall send a password reset email within 2 minutes of the request." Write one positive and one negative test case for this requirement.
What is the difference between a test scenario and a test case? Give a one-line definition of each.
What does 100% functional (requirement) coverage guarantee — and what does it NOT guarantee?

Summary & Assignment

Functional testing is the cornerstone of system-level verification. It validates that every stated requirement is correctly implemented by designing scenarios and test cases that cover positive, negative, and boundary conditions — all traceable back to the specification.

Key takeaways:

Functional testing derives tests from what the system should do, not how it does it.
Both positive and negative test scenarios are mandatory for meaningful coverage.
The Requirements Traceability Matrix is the primary tool for managing coverage and impact.
Expected results must be precise, unambiguous, and verifiable.

Assignment: Select two functional requirements from your mini-project SRS. For each requirement:

Identify all test scenarios (label each as positive, negative, or edge).
Write a complete test case for each scenario using the standard template.
Produce an RTM showing requirement-to-test-case traceability.
Execute the test cases and record actual results. Report any defects found using a standard defect report format.

Functional Testing Design

Learning Objectives