System Integration Test Plan Standard
Total Page:16
File Type:pdf, Size:1020Kb
System Integration Test Plan Standard
System Integration Test Plan Standard
for
[Project Name] [Version #]
[Date]
Page 1 of 8 11/11/2003 12:49:00 AM System Integration Test Plan Standard
System Integration Test Plan
Approvals Table of Contents 1. INTRODUCTION......
1.1 TEST OBJECTIVES...... 1.2 SCOPE OF TESTING...... 1.3 SYSTEM OVERVIEW...... 1.4 DEFINITIONS/ACRONYMS...... 1.5 REFERENCES...... 2. APPROACH......
2.1 ASSUMPTIONS/CONSTRAINTS...... 2.1.1 Assumptions...... 2.1.2 Constraints...... 2.2 COVERAGE...... 2.2.1 Software Components...... 2.2.2 Requirements...... 2.2.3 Business Processes...... 2.3 TEST TOOLS...... 2.4 TEST TYPE (REGRESSION, CONVERSION, ETC.)...... 2.5 TEST DATA...... 3. PLAN......
3.1 TEST TEAM...... 3.2 TEAM REVIEWS...... 3.3 MAJOR TASKS AND DELIVERABLES...... 3.4 ENVIRONMENTAL NEEDS...... 3.4.1 Test Environment...... 3.4.2 Test Lab...... 3.5 TRAINING...... 4. FEATURES TO BE TESTED......
5. FEATURES NOT TO BE TESTED......
6. TESTING PROCEDURES......
6.1 TEST EXECUTION...... 6.1.1 Test Cases...... 6.1.2 Order of Testing...... 6.2 PASS/FAIL CRITERIA...... 6.3 SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS...... 6.3.1 Normal Criteria...... 6.3.2 Abnormal Criteria...... 6.4 DEFECT MANAGEMENT...... 7. RISKS AND CONTINGENCIES......
8. APPENDIX......
8.1 APPENDIX A: WORK BREAKDOWN STRUCTURE......
Page 2 of 8 11/11/2003 12:49:00 AM System Integration Test Plan Standard
1. Introduction
This section provides an overview of system integration testing for a project. The introduction section describes the major test objectives, a general description of what will be tested, a general system overview, any unique definitions and acronyms, and references to be used during test planning and test execution.
1.1 Test Objectives
The test objectives describe what the test should accomplish. In most cases, the test objectives should be a high-level list that corresponds to the system or project objectives.
1.2 Scope of Testing
The scope of testing describes in general terms what will be tested and what will not be tested. The details of what will be tested are described in the section, Features to be Tested. The details of what will not be tested are described in the section, Features Not to be Tested.
1.3 System Overview
The system overview describes the system or project at a general level. If a graphical picture of the system is available, this is a good section to include it. The intent of this section is to provide the reader of the test plan an easily understandable view of the system or project.
1.4 Definitions/Acronyms
This topic is to provide definitions for any unique terminology or acronyms used in the test plan.
1.5 References
This topic describes the references used during test planning or testing. These references might include internal documents such as system requirements, system design, company policies and procedures, departmental testing standards, etc., or external documents such as testing reference books.
2. Approach
This section describes the approach that will be used for performing system level system integration testing. The system integration testing approach will address the assumptions and constraints; how many of the software components and requirements will be tested in terms of coverage percentage; the types of testing to be performed; and the kinds of test data that will be required for system integration testing.
Page 3 of 8 11/11/2003 12:49:00 AM System Integration Test Plan Standard
2.1 Assumptions/Constraints
This topic describes the conditions upon which system integration testing is based, and the constraints which may cause problems during testing.
2.1.1 Assumptions
Assumptions provide a common understanding of what should be in place for testing and what may happen in the event certain specified conditions occur.
2.1.2 Constraints
Constraints are those issues which are recognized as being inhibitors to the testing effort.
2.2 Coverage
This topic describes the strategy to achieve a specified degree of coverage in the system integration test. Coverage is described from the standpoint of system components (e.g., system modules, procedures, etc.) and requirements (e.g., user requirements that describe how the system should handle a specific business task).
This topic should specify how the system integration test coverage will be measured and what should occur in the event that the expected level of coverage is not met. The specific components and requirements to be tested will be described in the section, Features to be Tested.
2.2.1 Software Components
This item describes the level of coverage for the software components to be tested.
2.2.2 Requirements
This item describes the level of coverage for the requirements to be tested.
2.2.3 Business Processes
This item describes the level of coverage for the business processes to be tested.
2.3 Test Tools
This topic describes the tools to be used during the test.
2.4 Test Type (Regression, Conversion, etc.)
This topic describes the types of testing that will be performed during system integration testing. The types of testing will depend on the test objectives, who will be performing testing, the system risks, and how much time is available for testing.
Page 4 of 8 11/11/2003 12:49:00 AM System Integration Test Plan Standard
The following table shows possible tests that can be performed. This list is not intended to be exhaustive, but rather a starting point to help define testing.
Test Type Description Conversion Testing that validates converted data will work correctly in new software or systems. Compliance Testing that ensure the software or system complies with existing polices and procedures. For example, a payroll system would need to comply with corporate payroll policies and with government payroll regulations. Configuration Testing that validates the software or system will function correctly in all expected environments. Environments may consist of differences in operating systems, hardware, and networks. Functional Testing that is performed to validate software or systems functions based on specifications and/or other criteria. No knowledge of the software logic is used to develop test cases. Also known as black box testing. Load Testing that validates the software or system can process greater than expected numbers of transactions or concurrent users within specified times. Procedural Testing to validate the operating procedures (users guide, operator guide, etc.) describe correctly how to use the software or system. Performance Testing that validates the software or system processing times will meet specified criteria under greater than expected transaction load. Performance testing can also be called stress testing or load testing. Recovery Testing that ensures the software or system can be recovered in the event of a failure. Regression Testing that validates that the unchanged parts of the software or system work as before a change was made. Reliability Testing to validate that the software or system will work correctly each time it is invoked. Security Testing that ensures all access and authorization rules are enforced correctly in the software or system. Stress Testing that is performed to validate the maximum limits of the software or system. Structural Testing that is performed based on software or system structure. Also known as white box testing. Usability Testing that validates the degree of ease or difficulty a typical user has in using the software or system. This type of testing is usually performed by observing a group of users operating the software without being coached, but using only the system documentation and help facilities.
Page 5 of 8 11/11/2003 12:49:00 AM System Integration Test Plan Standard
2.5 Test Data
This topic will describe the kinds of data required for system integration testing. In addition, the source of test data should be specified. In the event that test data will need to be created, the general process to create the test data should be described.
3. Plan
The planning section describes how the system integration test will be conducted in terms of people, schedule, tasks, test environment, and training.
3.1 Test Team
The test team description lists who will be on the system integration test team, the level of their involvement in the test, and what their responsibilities will be during the test.
3.2 Team Reviews
This topic describes the team reviews that will take place during the test (e.g., test plan reviews, test case reviews, etc.).
3.3 Major Tasks and Deliverables
This topic describes the major tasks and dates for the system integration test. In addition, the deliverables from system integration testing should be described. The detailed work plan will be located in the Appendix of the test plan.
3.4 Environmental Needs
This topic describes the system integration test environment set-up.
3.4.1 Test Environment
The test environment describes the technical environment used during the system integration test. The technical environment may include hardware, database regions or versions, operating system versions, system libraries, communications software, security, etc.
3.4.2 Test Lab
The test lab describes the physical set-up where system integration testing will be performed. The system integration test lab section may include items such as the location of the test lab, the number of workstations or PCs, telephones, whiteboards, printers, supplies, etc.
Page 6 of 8 11/11/2003 12:49:00 AM System Integration Test Plan Standard
3.5 Training
This topic describes the kinds of training that will be required to enable people to perform system integration testing effectively. In addition, the source of training is described (e.g., vendor or in- house) and the dates of training are specified.
4. Features to be Tested
This topic describes all features and combinations of features that will be tested during system integration testing as defined in the system requirements. A feature may be defined as a functional requirement (such as being able to handle certain conditions), a behavior (such as usability), or a process to be supported by the system (such a business process of adding a customer).
5. Features Not to be Tested
This section describes those areas outside of the scope of system integration testing.
6. Testing Procedures
This section describes how system integration testing will be performed.
6.1 Test Execution
This topic describes how system integration testing will be performed in terms of test cases, test scripts, order of testing, etc.
6.1.1 Test Cases
This item describes test cases for the system integration test and how the testing process will use them.
6.1.2 Order of Testing
This item describes the order of testing and any dependencies or prerequisites that must be observed during testing.
6.2 Pass/Fail Criteria
This topic describes the criteria that must be met before the system or project will be ready for acceptance testing.
6.3 Suspension Criteria and Resumption Requirements
Page 7 of 8 11/11/2003 12:49:00 AM System Integration Test Plan Standard
This topic describes the criteria used to suspend all or a portion of the testing activity on the test items associated with this plan. This topic also describes the testing activities which must be repeated when testing is resumed.
There are two possible categories to be addressed: normal suspension of system integration testing and abnormal suspension of testing.
6.3.1 Normal Criteria
This item discusses the suspension of testing due to normal occurrences, such as reaching a certain milestone, end of day, etc.
6.3.2 Abnormal Criteria
This item discusses the suspension of testing due to abnormal occurrences, such as the failure of a critical system component.
6.4 Defect Management
This topic discusses how defect information will be collected, tracked, managed and reported. If a defect management tool will be used, it can be specified in this topic, as well as other information, such as severity and priority criteria.
7. Risks and Contingencies
This section describes the system or project risks and the contingency plans that should take effect if the project experiences problems.
8. Appendix
8.1 Appendix A: Work Breakdown Structure
This is the project plan which should include a detailed list of tasks and resources, along with a project time line for the system integration test.
Page 8 of 8 11/11/2003 12:49:00 AM