Purpose:

<?>

Objective:

<?>

Description:

Testing the system involves planning, designing test cases, implementing and executing the tests. This process covers the test planning, designing of test cases and development of test scripts. Test scripts may not be required in the project and is applicable only for projects using testing tools. In developing the Test Strategy, the approach for using a test tool is determined and documented.  The Test Strategy determines the approach and documents the approach of using a testing tool.

The Test Plan document shall contain the test procedure and schedule, including the resources and effort required for testing. Projects shall have plans and clearly identify the responsibility of testing in the project’s Test Strategy Document. Projects shall develop a Test Plan for System Testing and User Acceptance Testing. The testing work products produced from this process are User Acceptance Test Plan (UATP) and System Test Plan (STP).

When outsourcing, it is expected that the Supplier shall develop the Test Plan for Supplier conducted tests such as Unit Testing and Integration Testing.  

Inputs:

<?>

Outputs:

<?>

Controls:

<?>

Task Instructions:

Develop Test Strategy

    1. The Test Strategy is created during Define phase and forms the basis for the different types of testing to be conducted in the project’s life cycle. SDP-21 proposes four types of testing to validate the system or the product that is being developed. These are Unit Testing, Integration

      Testing, System Testing and User Acceptance Testing. When an organization operates in an outsourced environment for the Construct through Deploy phases, the Supplier shall conduct Unit and Integration Testing at their location before delivering the system.

      The Project Manager documents the Test Strategy, as part of the Product Quality Plan (PQP); to ensure that appropriate test types have been identified along with their approaches and with the organization responsible for conducting the test. Based on the project’s needs, the Project Manager shall plan the types of testing and shall add or remove test types from the Test Strategy as appropriate. At a minimum, the organization is  responsible for User Acceptance Testing.

      Refer to Appendix A of this process document for ‘Overview of Testing Types,’ which lists the system validations done for projects. The Test Strategy Worksheet of PQP shall be completed by Project Manager during the development of the Final Project Plan and shall be reviewed along with the Project Plan. For details regarding review of Project Plan, refer to Project Management Process. The Project Manager shall consult the System Deployment Manager and the Test Manager to identify the test types and the dependencies on the test environments.

Develop Test Plans

    1. Document User Acceptance Test (UAT) Cases
      • The User Acceptance Test Cases shall be the criteria against which the Business Group and the End-Users shall accept the system. It shall include test cases for Functional Requirements and some Non-functional Requirements that were provided by the End-Users as requirements.

        Supplier shall identify and document the User Acceptance Test Cases after understanding the BRD and SRS documents. The Test Case Template shall be used to document User Acceptance Test Cases. User Acceptance Test Cases shall be run by End-Users. The Operations Team and/or Deployment Team shall run Non-functional Test Cases.

    2. Update User Acceptance Test Case References in RTM
      • Supplier shall update the Requirements Traceability Matrix (RTM) with references to the User Acceptance Test Cases in order to provide traceability between the business and system requirements and the appropriate User Acceptance Test Case. This helps primarily to ascertain the complete coverage of the requirements and provide traceability for maintaining the system.
    3. Review User Acceptance Test Cases
      • Project Manager shall ensure that the User Acceptance Test Cases are reviewed for completeness, accuracy and are unambiguous. The Project Manager shall identify the appropriate reviewers so that the review is effective. The review team to review User Acceptance Test Cases shall, typically, consist of the Process Engineer, some End-Users, Requirements Providers and Requirements Analyst.

        The reviewers shall use the Review Log to record their feedback on User Acceptance Test Cases. The Supplier shall incorporate the review feedback.

    4. Document Non-functional Test Cases
      • Supplier shall use the SRS and AD documents to identify the Non-functional Acceptance Test Cases to validate the Architectural and Non-functional Requirements. These test cases verify the interoperability of the system by validating whether the system is implemented for the target Production environment, and interfaces with relevant GM IT systems and infrastructure.
    5. Update Non-functional Test Case References in RTM
      • Supplier shall update the Requirements Traceability Matrix (RTM) with references to the Non-functional Acceptance Test Cases in order to provide traceability between the appropriate system requirements and the appropriate Non-functional Acceptance Test Cases identified. 
    6. Review Non–Functional Test Cases
      • The Project Manager shall ensure that the Non-functional Test Cases are reviewed before entering as baseline to the CM repository. The Project Manager shall identify the appropriate reviewers from the Deployment, Test and Operations Teams to ensure that the review is effective. The Review Team for reviewing the Non-functional Acceptance Test Cases shall typically be the Project Architect, SMEs from Deployment team, Test Engineers, Test Manager and SMEs from Operations Team.

        The reviewers shall use the Review Log to record their feedback on Non-functional Acceptance Test Cases. The Supplier shall incorporate the review feedback to the Non-functional Acceptance Test Cases.

    7. Obtain Approval and Baseline Acceptance Test Cases
      • The Supplier shall modify the Acceptance Test Cases to incorporate the review comments and feedback from the Review Team. Project Manager shall capture the issues and risks, if any, related to Acceptance Testing in the Project Log and Risk Management Plan respectively, to track and close them effectively.
      • Project Manager shall ensure that BRD, SRS and Acceptance Test Case Document are consistent and that there are no open issues to Acceptance Test Case Document baseline.
      • Project Manager shall request and obtain e-mail approval from the Process Engineer to baseline the Acceptance Test Cases. Project Manager shall review and approve the Non-functional Acceptance Test Cases by verifying if the review feedback is incorporated effectively in the document.
      • Project Manager shall coordinate with the CM Lead to baseline the Acceptance Test Cases.
      • Project Manager shall communicate the Acceptance Test Case baseline to the System Deployment Manager and Test Manager to keep them informed of the progress. Any further changes to the Acceptance Test Cases baseline shall be done in a controlled manner as per the Change Control Process.