System Integration Testing

Details

• QA should begin preparing a QA Test Plan, with adequate time before the development phase is scheduled to end (development exit) to complete the plan, as well as allow for management review, updates, and approvals. This is usually a task in the overall project plan. The test plan has the following sections:
  1. Introduction
  2. Testing Scope
  3. Testing Approach
  4. Testing Deliverables
  5. High-Level Schedule
  6. Error Management & Reporting
  7. Environmental Requirements
  8. Roles & Responsibilities
  9. Risks & Assumptions
  10. SIT Exit Criteria

  Approvals of the SIT Plan should be obtained and recorded from the Project Manager, the QA Director, and the Project Sponsor, Business Owner, or designee before proceeding with SIT testing.

• Test cases should be prepared by QA, again allowing adequate time for review and approval by the QA Director, and again ensuring that they are complete, approved, and loaded to Zephyr before development exit. And again, this should be a task in the project plan. Best practice is to start with the business use cases; however, QA usually develops a comprehensive set of functional test cases as well.
• QA should provide weekly status updates on their page in the project Confluence (or via Box, Shared drives, etc.) that include: (1) completed test cases/scope from the reporting week; (2) planned test cases/scope for the coming week; (3) any issues, concerns, or blockers. A high-level synopsis of QA status should be included in the Executive Summary Report during the weeks that the project is in the SIT phase.
• Performance testing is typically designed and validated during the SIT phase in the QA/INT environment and tasks for both should be added to the project plan. The test execution is normally performed by QA at a quiet time during UAT testing since the UAT environments are usually closer to the production environments, in terms of performance.
• As outlined in Business Requirements, for traceability, best practice is to ensure QA links all bugs logged in JIRA to both the corresponding Zephyr test case and the applicable business requirement JIRA issue. This practice can help mitigate disagreement among project team members about what is a bug and what is a change request.
• Be sure to follow the change control process (for more information, see Scope Management) closely during SIT, especially if business users will be permitted to access the QA/INT environment. The more changes that are requested and accepted during SIT, the more likely it is that regression bugs will crop up. Best practice is to always allow at least 1 - 2 weeks of regression testing at the end of SIT testing, before which time all baseline test cases should have been executed.
• The Project Manager, QA Manager/Director, and the QA Lead must grant approval for the project to exit SIT. Entering UAT requires approval from the business' Project Sponsor. For an example of SIT Exit Criteria from a previous project see FSS. While open P1 - P3 bugs are strongly discouraged at SIT Exit, if the Project Sponsors agree, lower priority bugs may be listed as exceptions on the SIT Exit Criteria document/page. Any outstanding high priority changes and enhancements which are still open at SIT Exit should also be listed as exceptions.