# Verification Strategy and Test Implementation

**Course:** SE 300 Software Engineering Practices  
**Term:** Spring 2026  
**Project:** _Resume Lens_  

## 1) Verification Philosophy

Our verification strategy is designed to show that the software is:

- **Correct**: Implements the requirements defined in the SRD/SDD.
- **Reliable**: Behaves consistently under expected and edge-case conditions.
- **Safe in process**: Developed using disciplined engineering practices (reviews, traceability, repeatable tests).

To achieve this, we use a combination of:

- **Testing** (unit, integration, and system-level)
- **Reviews** (design and code reviews)
- **Analysis** (static checks and traceability analysis)

This layered approach helps us detect defects early, validate behavior continuously, and provide objective evidence of quality.

## 2) Verification Approach Overview

We combine **black-box** and **white-box** techniques:

- **Black-box testing** validates external behavior against requirements without relying on internal code structure.
- **White-box testing** validates internal logic paths, branches, and error handling.

Testing is organized by level:

- **Unit Testing**: verifies individual functions/classes/modules.
- **Integration Testing**: verifies interactions between modules/interfaces.
- **System Testing**: verifies end-to-end behavior from a user perspective.

Techniques used include:

- **Boundary Value Analysis**
- **Equivalence Partitioning**
- **Negative/Error-condition testing**
- **Regression testing** after changes

## 3) Test Case and Test Procedure Structure (1:M)

We follow a 1:M hierarchy:

- A **Test Case (TC)** targets one behavior/requirement area.
- Each TC has one or more **Test Procedures (TPs)** that define concrete execution scenarios.

Example:

- **TC-INPUT-01**: Validate user input handling
  - **TP-INPUT-01A**: Valid input accepted
  - **TP-INPUT-01B**: Empty input rejected
  - **TP-INPUT-01C**: Over-length input rejected
  - **TP-INPUT-01D**: Invalid characters handled safely

## 4) Requirement Traceability

Every test case maps to one or more requirements from the SRD/SDD, and code blocks include trace tags tied to LLD/HLD tags.

Traceability chain:

`Requirement ID -> Design Tag (LLD/HLD) -> Code Trace Tag -> Test Case ID -> Test Procedure ID -> Result Evidence`

This ensures we can prove coverage from requirements through implementation and verification.

## 5) Test Artifacts and Implementation

For each test we maintain:

- **Test Case ID and objective**
- **Mapped requirement/design tags**
- **Preconditions**
- **Inputs/test data**
- **Steps**
- **Expected result**
- **Actual result**
- **Pass/Fail status**
- **Execution date and tester**
- **Evidence** (logs, screenshots, reports)

Execution is repeatable using the team's build/test commands (e.g., CI or local scripts), enabling consistent regression checks.

## 6) Planned Test Cases (Summary)

> Replace IDs/content below with your project-specific items.

### TC-FUNC-01: Core Feature Behavior

- **Purpose**: Verify primary functional requirement(s).
- **Type**: Black-box, system test.
- **Procedures**:
  - TP-FUNC-01A normal flow
  - TP-FUNC-01B alternate valid flow
  - TP-FUNC-01C invalid input flow

### TC-BOUND-02: Boundary Conditions

- **Purpose**: Verify behavior at min/max/edge values.
- **Type**: Black-box + white-box, unit/integration.
- **Procedures**:
  - TP-BOUND-02A minimum boundary
  - TP-BOUND-02B maximum boundary
  - TP-BOUND-02C just-below/just-above boundary

### TC-ERROR-03: Error Handling and Recovery

- **Purpose**: Verify robustness under invalid states/failures.
- **Type**: White-box + integration.
- **Procedures**:
  - TP-ERROR-03A null/empty references
  - TP-ERROR-03B invalid format/type
  - TP-ERROR-03C dependency/service unavailable

### TC-INT-04: Module Interaction

- **Purpose**: Verify data flow and contract compliance across components.
- **Type**: Integration.
- **Procedures**:
  - TP-INT-04A successful data exchange
  - TP-INT-04B malformed payload handling
  - TP-INT-04C timeout/retry behavior (if applicable)

### TC-REG-05: Regression Suite

- **Purpose**: Ensure prior functionality remains intact after changes.
- **Type**: Automated regression (unit/integration/system mix).
- **Procedures**:
  - TP-REG-05A smoke tests
  - TP-REG-05B critical-path revalidation

## 7) Reviews and Analysis Procedures

### 7.1 Design/Artifact Reviews

- Review SRD/SDD/LLD consistency before implementation.
- Confirm each requirement is testable and traceable.

### 7.2 Code Reviews

- Peer review for all significant changes.
- Checklist includes:
  - requirement trace tag present
  - correctness and readability
  - error handling
  - test coverage impact
  - no unintended side effects

### 7.3 Static Analysis

- Use compiler/linter/static tools to detect:
  - syntax/type issues
  - dead code
  - obvious anti-patterns
  - potential reliability concerns

## 8) Entry/Exit Criteria

**Entry criteria (before running verification):**

- Build succeeds.
- Required environment/dependencies available.
- Relevant test data prepared.
- Requirement-to-test mappings updated.

**Exit criteria (verification complete):**

- All planned TCs executed.
- Critical tests pass.
- Failed tests triaged with disposition.
- Traceability matrix updated.
- Evidence package assembled.

## 9) Deliverable Contents (Verification Package)

The verification package includes:

- This verification philosophy and strategy document.
- Full list of test cases and test procedures.
- Review and analysis procedure descriptions.
- Requirement/design/code/test traceability matrix.
- Test execution evidence and pass/fail report.

## 10) Demo Readiness (In-Class)

For the in-class demo, we will prepare:

- A brief walkthrough of core features.
- A short explanation of verification approach.
- Selected test evidence demonstrating correctness and reliability.
- Q&A support materials (requirements map, traceability, test summary).