System Integration Testing (SIT) Process

PURPOSESCOPEPROCESS DESCRIPTIONPROCESS INPUTS/OUTPUTSSUPPORTING DOCUMENTATIONREVISION HISTORY

Process Owner: Manager, Business Relationship Management

Note: An owner must be a PCES-level manager.

This document establishes standard processes for the Technology Solution Life Cycle (TSLC) Agile (Release) System Integration Testing (SIT) and Waterfall SIT phase within the Postal Service Technical Environment.

PURPOSE

The SIT process validates that the Technology Solution and its features conform to the Technology Solution Design specifications and the Technology Solution Requirements, prior to Customer Acceptance Testing (CAT).

The objectives of the Technology Solution SIT process are:

SCOPE

This process applies to all:

Exemptions:

PROCESS DESCRIPTION

The SIT Process consists of the following subprocesses. Baseline artifacts are mandatory and must be uploaded. Baseline artifacts are indicated in this document by an asterisk (*).

  1. Follow the Certification and Accreditation Process.
  2. The Business Relationship Management Program Manager (BRM PM) coordinates this task.

    For security-related processes and artifacts, follow the Certification and Accreditation Process as described in the Handbook AS-805A, Information Resource Certification and Accreditation Process.

  3. PCI in-scope only: Develop and Maintain Secure PCI In-Scope Systems and Applications.
  4. The BRM PM coordinates this task.

    Ensure that all requirements listed and referenced in the Develop and Maintain Secure PCI In-Scope Systems and Applications are met.

  5. Finalize SIT Documentation.
  6. The Technology Solution Coordinator (TSC) performs the following tasks:

  7. Perform SIT.
  8. The TSC coordinates this task.

    Execute the SIT Plan. All SIT results are documented. See Update Requirements Traceability Matrices (RTMs) for additional information.

  9. Analyze *SIT Results.
  10. The TSC coordinates this task.

    Review the SIT results and determine if the Technology Solution meets the Approved Technology Solution Requirements.

    Document all known issues and explanations of failures and workarounds with the SIT Results. All test results must be retained in accordance with Postal Service data retention requirements. If an issue results in a change to the accepted Technology Solution Requirements or Design documents, it must be logged and submitted to the Change Control Board (CCB). Problems must be entered, prioritized, and resolved prior to the CAT process.

  11. Update Requirements Traceability Matrices (RTMs).
  12. The BRM PM coordinates this task.

    RTMs must be updated to reflect final SIT scripts, results, and any SIT exemptions. If the SIT scripts, results, and/or exemptions are not documented in the RTM, the RTM must include mapping to SIT/CAT Scripts and results documents that address each requirement in the RTM.

  13. Obtain *Documented SIT Approval.
  14. The TSC coordinates this task.

    The purpose of this activity is to create a formal checkpoint and documentation of acceptance of the as-built tested Technology Solution. Upon acceptance, the approver, as stated in the CCB Document, provides documented approval. The accepted Technology Solution may now begin its migration to the CAT environment through the Release Management process. This is a Baseline requirement, for all systems, that must be stored in the TSLC Artifacts Library.

  15. Review the Impact Assessment.
  16. The BRM PM reviews the SOX Impact Assessment (SIA) to determine whether changes that have been made impact the assessment. If changes do impact the assessment, update and resubmit the Impact Assessment(s). If the Impact Assessment is updated, it must be submitted to the SOX CCB at least 30 days prior to implementation. Changes with a planned implementation date within the high-risk period must be submitted at least 45 days prior to the implementation date.

  17. PCI In-Scope Only: Conduct Code Review.
  18. The Payment Card Industry Data Security Standard (PCI DSS) requires review of all custom code to identify potential coding vulnerabilities and correction of coding vulnerabilities prior to release to production. The Secure System Review Process must be followed for all PCI in-scope applications within the US Postal Service Chief Information Officer (CIO) organization.

  19. Upload Documents to the TSLC Artifacts Library.

  20. The BRM PM ensures that the following artifacts are uploaded to the TSLC Artifacts Library in the appropriate folders:

PROCESS INPUTS/OUTPUTS

Baseline artifacts are mandatory and must be uploaded prior to release to production unless the project is following the Tollgate process. If Tollgate, documents from the Tollgate must be uploaded within 10 business days. Baseline artifacts are indicated in this document by an asterisk (*).

Inputs

Outputs

SUPPORTING DOCUMENTATION

Access supporting documentation from ITWEB (Internal):

Access Supporting Documentation from USPS.com (external):

REVISION HISTORY

Version
Date
Description of Change
1.0 05.10.2013 Agile and Waterfall processes combined; updated for Tollgates, PCI, and general compliance; ownership of TSLC processes transferred from Manager, Solutions Development and Support, to Manager, Business Relationship Management.

Note: This document is Section 508 compliant.
1.1 08.16.2013 Scope:
Updated to clarify that the Requirements must be approved, not the Requirements Traceability Matrix document.
1.2 03.18.2014 Process Inputs/Outputs:
Updated "baseline artifacts" statement to clarify that they must be uploaded prior to release unless the project is following the Tollgate process. If Tollgate, required Tollgate artifacts must be uploaded within 10 business days.
1.3 02.10.2015 Process, Process Inputs/Outputs:
Removed references to PCI Impact Assessment artifact. PCI Impact Assessment is retired.
1.3.1 06.15.2015 The annual review for functional accuracy and current PCI DSS requirements has been completed: No changes. CR 81805
1.3.2 06.26.2015 Non-substantive update: Update CR for annual review. Remove link and version of PCI DSS.
1.3.3 03.14.2016 Annual Review: No changes. The annual review for functional accuracy and current PCI requirements has been completed. CR 154951
1.3.4 10.31.2016 Annual Review: The annual review for functional accuracy and current PCI requirements has been completed. CR 223948
Powered By OneLink