Waterfall Quality Assurance Documents

My preferred standard IEEE 829, is a standard for software and system test documentation. Its primary focus is to provide a structured approach to creating and maintaining documentation throughout the software testing process. Here’s a summary of its key aspects:

I consider Waterfall test document to sit under three headings which are based on who needs those documents

  1. Company Level
    • Test Policy
  2. Programme Level
    • Test Strategy or Master Test Plan
  3. Project Level
    • Level Test Plan

Core Purpose:

  • Standardisation:
    • IEEE 829 establishes a consistent format and content for test documents, ensuring clarity and uniformity across testing activities.
  • Comprehensive Documentation:
    • It outlines the creation of various documents that cover all phases of testing, from planning to reporting.
  • Improved Communication:
    • By standardising documentation, it facilitates better communication among team members, stakeholders, and other involved parties.
  • Enhanced Quality Control:
    • The detailed documentation aids in identifying defects, tracking progress, and evaluating the overall quality of the software.

Key Document Types:

IEEE 829 defines several essential document types, including:

  • Test Policy:
    • Outlines the quality assurance principles for the company and the high level test assurance which should apply to all projects
  • Master Test Plan (MTP) / Test Strategy:
    • Outlines the high level scope, the test stages which will be covered, the approach to testing, the expected hardware infrastructure, the resources, and schedule of testing activities. The MTP directly relates to the cost and schedule for delivering the project.
      • (If testing is late or the test costs is more than budgeted for, the author of this document is accountable)
    • The MTP Identifies the different test stages which are covered by the Level Test Plans (LTP). These can be different departments within the same company or third party companies which specialise in the specific test discipline, i.e
      • Functional Testing
        • Unit Testing (often covered by development and automated)
        • System Integration Testing (SIT)
          • the system deployment section should be automated and hardware audited so testing is against the right hardware and configuration
        • Regression Testing
        • Integration Testing (Cross device and interoperability across different ecosystems)
        • User Acceptance Testing (UAT)
        • Operational Acceptance Testing (OAP)
      • Non-Functional Testing
        • Hardware Testing
        • Performance and Load Testing
        • Data Migration
        • Security Testing
        • Disaster Recover
  • Level Test Plan: (Test Stages)
    • Based at the test stage level the Level Test Plan identifies much more detail of the scope for the Test stage, approach, resources, and schedule of testing activities.
    • Test Design Specification:
      • Details the test cases, features to be tested, and pass/fail criteria.
    • Test Case Specification:
      • Specifies the inputs, expected results, and execution conditions for individual test cases.
    • Test Procedure Specification:
      • Describes the steps for executing each test case.
    • Test Log:
      • Records the chronological details of test execution.
    • Defect Report:
      • Documents any discrepancies or issues encountered during testing.
    • Test Summary Report:
      • Provides an overview of the testing activities, results, and evaluations.

Benefits:

  • Traceability:
    • Enables the tracking of test cases back to requirements, ensuring comprehensive test coverage.
    • Identifies project slippage or costs increase and supplies direct traceability back to the author and sign off signatures within the Master Test Plan
  • Efficiency:
    • Streamlines the testing process by providing clear guidelines and standardised templates.
  • Auditability:
    • Facilitates audits and reviews by providing organised and detailed documentation.
  • Adaptability:
    • While providing a framework, it allows for tailoring the documentation to specific project needs.

In essence, IEEE 829 provides a valuable framework for creating thorough and effective software testing documentation with traceability back to the budget and schedules.

Project Waterfall documentation following the entire software and hardware delivery life cycle starts from 6 main documents

  • (1) Contract Documentation
  • (2) Architectural Design Document
  • (3) Functional Requirements Specification
  • (4) Functional Specification
  • (5) Non Functional Specification
  • (6) Technical Specification