ResumeLens/doc/verification-strategy.md

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).