Testing

Software testing is the process of evaluating a program to determine whether it meets specified Requirements and to identify defects.

1. Correctness: Verify the program produces expected outputs
2. Reliability: Ensure consistent behaviour under various conditions
3. Security: Identify vulnerabilities
4. Performance: Verify the program meets efficiency requirements
5. Compliance: Meet regulatory and safety standards

Definition: Testing individual components (functions, methods, classes) in isolation.

def add(a, b):
    return a + b

def test_add():
    assert add(2, 3) == 5
    assert add(-1, 1) == 0
    assert add(0, 0) == 0
    assert add(100, 200) == 300

Characteristics:

• Written by developers
• Fast to execute
• Isolate dependencies using mocks and stubs
• High coverage of individual code paths

Definition: Testing interactions between integrated components or modules.

Approaches:

Definition: Testing the complete, integrated system against its requirements.

Types:

• Functional testing: Does the system do what it should?
• Non-functional testing: Performance, usability, security, reliability
• Regression testing: Re-run tests after changes to ensure nothing broke

Definition: Testing by the customer or end-user to determine if the system meets their Requirements.

Black-box testing tests the functionality of a system without knowledge of its internal Implementation. Tests are based on requirements and specifications.

Divide input data into equivalence classes — groups of inputs that the system should treat the Same way. Test one representative from each class.

Example: A function accepts ages 0-120.

Test values at the boundaries of equivalence classes, where errors are most likely to occur.

Rules: Test the boundary value, and the values immediately above and below.

Example: Age range $[0, 120]$:

Why boundaries? Off-by-one errors are among the most common programming mistakes. If a developer Writes age < 120 instead of age <= 120Boundary testing catches it immediately.

Create a table listing all combinations of conditions and the expected actions.

Test the transitions between states of a system that can be in different states.

Example: A login system has states: Logged Out → Authenticating → Logged In → Locked.

White-box (structural) testing uses knowledge of the internal code structure to design tests. Tests are based on code paths, branches, and conditions.

Definition: The percentage of executable statements that have been executed by the test suite.

$\mathrm{Statement coverage} = \frac{\mathrm{Statements executed}}{\mathrm{Total statements}} \times 100\%$

Definition: The percentage of decision outcomes (true/false branches) that have been taken.

$\mathrm{Branch coverage} = \frac{\mathrm{Branches taken}}{\mathrm{Total branches}} \times 100\%$

Theorem. 100% statement coverage does not imply 100% branch coverage.

Proof. Consider:

if condition:
    x = 1
x = 2

A single test with condition = True achieves 100% statement coverage (all 2 statements executed) But only 50% branch coverage (the false branch of the if-statement is never taken). $\square$

Definition: The percentage of distinct execution paths through the code.

Theorem. 100% path coverage is infeasible for programs with loops (exponentially many paths).

1. Red: Write a failing test for the desired functionality
2. Green: Write the minimum code to make the test pass
3. Refactor: Improve the code while keeping tests green

• Forces consideration of the interface before implementation
• Comprehensive test suite as a by-product
• Confidence in refactoring
• Self-documenting code through tests

Traceability links requirements to test cases, ensuring every requirement is tested and every Test case maps to a requirement.

Requirement → Design → Code → Test Case → Test Result

A traceability matrix maps each requirement to the test cases that verify it.

Problem 1. A function calculate_discount(price, age) applies a discount based on age:

• Children (0-12): 50% discount
• Seniors (65+): 30% discount
• Teenagers (13-17): 10% discount
• Adults (18-64): no discount

Using equivalence partitioning and boundary value analysis, identify all test cases.

Problem 2. Explain the difference between a stub and a mock in unit testing.

Problem 3. Consider the following code. What is the minimum number of test cases to achieve 100% Branch coverage?

def classify(x, y):
    if x > 0:
        if y > 0:
            return "Q1"
        else:
            return "Q4"
    else:
        if y > 0:
            return "Q2"
        else:
            return "Q3"

Problem 4. Write unit tests for a stack’s push, pop, and peek operations. Include edge cases.

def test_stack():
    s = ArrayStack(5)

    s.push(10)
    assert s.peek() == 10
    assert s.size() == 1

    s.push(20)
    assert s.peek() == 20
    assert s.pop() == 20
    assert s.peek() == 10

    assert s.pop() == 10
    assert s.is_empty()

    try:
        s.pop()
        assert False, "Should have raised"
    except Exception:
        pass

    try:
        s.peek()
        assert False, "Should have raised"
    except Exception:
        pass

Problem 5. Explain why 100% statement coverage does not guarantee bug-free code. Give a concrete Example.

def process(data):
    result = []
    for item in data:
        if item > 0:
            result.append(item * 2)
        result.append(item)
    return result

Problem 6. Describe the difference between top-down and bottom-up integration testing. What are The advantages of each?

Problem 7. Create a decision table for a login system where a user can be:

• Valid or invalid
• Have correct or incorrect password
• Account may be locked (after 3 failed attempts)

Problem 8. Explain the concept of regression testing and why it is necessary in iterative Development.

A system requires passwords to be 8-20 characters long, containing at least one uppercase letter, One digit, and one special character.

Boundary value analysis for length:

Equivalence partitioning for character requirements:

A function accepts dates in the format DD/MM/YYYY where the year must be between 1900 and 2100.

Equivalence classes:

Boundary values for year: 1899, 1900, 1901 and 2099, 2100, 2101

Additional boundary values for day: Test February 29 (leap year): 29/02/2024 (accept), 29/02/2023 (reject)

A stack has a maximum capacity of 5 elements. Operations: push(item)``pop()``peek() is_empty()``is_full().

Write failing test → See it fail (Red) → Write minimum code → See it pass (Green) → Refactor → Repeat

Step 1 (Red): Write a test.

def test_is_prime():
    assert is_prime(2) == True
    assert is_prime(17) == True
    assert is_prime(1) == False
    assert is_prime(4) == False

Run the test — it fails because is_prime does not exist.

Step 2 (Green): Write the minimum code to pass.

def is_prime(n):
    if n < 2:
        return False
    for i in range(2, n):
        if n % i == 0:
            return False
    return True

Run the test — all tests pass.

Step 3 (Refactor): The loop can be optimised.

def is_prime(n):
    if n < 2:
        return False
    if n == 2:
        return True
    if n % 2 == 0:
        return False
    for i in range(3, int(n**0.5) + 1, 2):
        if n % i == 0:
            return False
    return True

Run the test — still passes. The refactored version is more efficient.

Step 4 (Add more tests): Test edge cases discovered during refactoring.

def test_is_prime():
    assert is_prime(2) == True
    assert is_prime(3) == True
    assert is_prime(17) == True
    assert is_prime(1) == False
    assert is_prime(0) == False
    assert is_prime(-5) == False
    assert is_prime(4) == False
    assert is_prime(9) == False
    assert is_prime(49) == False

Problem 1. A function calculate_bmi(weight_kg, height_m) returns a BMI category:

• BMI < 18.5: “Underweight”
• 18.5 <= BMI < 25: “Normal”
• 25 <= BMI < 30: “Overweight”
• BMI >= 30: “Obese”

Using boundary value analysis, identify all boundary test cases.

Problem 2. A function merge_sorted(a, b) merges two sorted arrays into one sorted array. Write A set of test cases using equivalence partitioning.

Problem 3. Explain why a test that achieves 100% branch coverage might still miss a bug. Provide A concrete code example.

def triangle_area(a, b, c):
    if a + b > c and b + c > a and a + c > b:
        s = (a + b + c) / 2
        area = (s * (s - a) * (s - b) * (s - c)) ** 0.5
        return area
    return -1

Problem 4. Describe how you would apply TDD to develop a function that converts a Roman numeral String to an integer.

def test_roman_to_int():
    assert roman_to_int("I") == 1
    assert roman_to_int("V") == 5
    assert roman_to_int("X") == 10

def roman_to_int(s):
    values = {"I": 1, "V": 5, "X": 10}
    return values[s]

    assert roman_to_int("III") == 3
    assert roman_to_int("IV") == 4
    assert roman_to_int("IX") == 9
    assert roman_to_int("LVIII") == 58
    assert roman_to_int("MCMXCIV") == 1994

def roman_to_int(s):
    values = {"I": 1, "V": 5, "X": 10, "L": 50, "C": 100, "D": 500, "M": 1000}
    total = 0
    for i in range(len(s)):
        if i + 1 < len(s) and values[s[i]] < values[s[i + 1]]:
            total -= values[s[i]]
        else:
            total += values[s[i]]
    return total

    assert roman_to_int("") == 0

Problem 5. A software team has 500 test cases. Running all tests takes 2 hours. After a code Change, the team only wants to run the tests most likely to fail. Describe a strategy for selecting Which tests to run.

1. Assuming 100% branch coverage means bug-free code. Branch coverage tests control flow, not data ranges, data types, or arithmetic properties. A function can have correct control flow but incorrect logic for specific data values (e.g., negative inputs, overflow, empty lists).

2. Confusing stubs with mocks. A stub provides canned responses to test data; a mock verifies interactions (which methods were called, with what arguments). Use stubs when you need test data, and mocks when you need to verify that code correctly calls dependencies.

3. Using floating-point division for binary search midpoints. Using mid = (low + high) / 2 in languages like C/Java can cause integer overflow when low + high > INT_MAX. The safe form is mid = low + (high - low) / 2.

4. Forgetting edge cases in test design. Always test: empty input, single element, already sorted data, maximum size, negative numbers, and boundary values. Off-by-one errors are among the most common bugs and are caught by boundary value analysis.

5. Writing tests that depend on execution order. Each test should set up its own state and clean up after itself. Tests that depend on previous tests produce false passes (a bug masked by a prior test) or false failures (a test fails because a previous test didn’t clean up).

This topic covers the core concepts of testing, including underlying theory, practical implementation, and key applications.

Key concepts include:

• CPU architecture and the fetch-decode-execute cycle
• memory hierarchy (cache, RAM, virtual)
• input/output systems
• operating systems and scheduling
• interrupts and polling

Understanding these concepts thoroughly is essential for both examinations and practical programming, and requires both theoretical knowledge and hands-on practice.

Testing is fundamentally about building confidence in code by systematically checking that it behaves as expected. Think of it like proofreading an essay, but with much higher stakes and stricter rules. You are not just checking for typos; you are verifying that every branch of logic produces the correct output for every possible input. The different levels of testing — unit, integration, system, and acceptance — mirror how you might check a building: first each brick, then each wall, then the whole structure, and finally whether it meets the client’s needs.

The real insight behind testing strategies like white-box and black-box is about perspective. White-box testing lets you peer inside the code and design tests that exercise every path, catching hidden bugs in logic you might otherwise miss. Black-box testing pretends you cannot see the implementation at all and asks: does the system do what the specification says? Both perspectives are essential because they catch different classes of errors. A function might pass every specification test yet still contain an unused code path with a latent bug, or conversely, every line of code might be tested but the specification itself might be wrong.

Test coverage metrics give you a numerical sense of how thoroughly your tests exercise the code, but they are a guide, not a guarantee. Achieving 100% line coverage means every line was executed at least once — but it does not mean every combination of inputs was tried. The practical takeaway is to write tests early, test incrementally, and prioritise the most critical and complex parts of the system. Automated testing turns what would be an impossibly tedious manual task into something that runs in seconds, letting you refactor and extend code with confidence.