Software Test Plan for XXXX Software System (abridged version for COS80010 assignment purposes) Table of Contents Section 1Introduction3 Section 1.1Input, output and operational environment of...

Price


Software Test Plan for XXXX Software System (abridged version for COS80010 assignment purposes) Table of Contents Section 1Introduction3 Section 1.1Input, output and operational environment of software under test3 Section 1.2Functional Requirements of the software under test3 Section 1.3Non-functional Requirements of the software under test3 Section 1.4Testing objectives and scope3 Section 2Test strategies and procedure3 Section 2.1Unit Testing3 Section 2.1.1Definition3 Section 2.1.2Overview of Items to be Tested4 Section 2.1.3Unit Test Plan for >4 Section 2.1.4Unit Test Plan for >4 Section 2.2Integration Testing4 Section 2.2.1Definition4 Section 2.2.2Overview of Items to be Tested5 Section 2.2.3Integration Test Plan for >5 Section 2.2.4Integration Test Plan for >5 Section 2.3Functional (System) Testing5 Section 2.3.1Definition5 Section 2.3.2Overview of Features to be Tested5 Section 2.3.3Functional Test Plan for >6 Section 2.3.4Functional Test Plan for >6 Section 2.4Performance Testing (Non-Functional System Testing)6 Section 2.4.1Definition6 Section 2.4.2Overview of “Non-functional” Requirements to be Tested6 Section 2.4.3Volume Testing (Non-Functional System Testing)6 Section 2.4.4Load Testing (Non-Functional System Testing)7 Section 2.4.5Overall Performance Testing (Non-Functional System Testing)7 Section 3Test scheduling and resource planning7 Section 4Test automation and tool selection / adopting7 Section 5Test result collection, evaluation and reporting7 Section 1Introduction This section discusses the background of the software project and its objectives. What are the things that can be achieved by the software project? It also discusses the aim of the testing of this project. Section 1.1Input, output and operational environment of software under test This subsection should outline the hardware and software environment under which the software under test should operate (e.g. any specific input devices such as bar-code scanner). Section 1.2Functional Requirements of the software under test This subsection should outline all functional requirements of the software under test at a high level. Section 1.3Non-functional Requirements of the software under test This subsection should outline all non-functional requirements of the software under test at a high level. Section 1.4Testing objectives and scope This subsection should describe the testing objectives of this test plan document, that is, what you want to achieve via the testing outlined in this document. It also outlines the scope of your test plan which includes “what are supposed to be tested” and “what are not supposed to be tested” as out of scope items. Section 2Test strategies and procedure This section discusses the software testing strategies and procedures. It gives an overall picture of the different levels of testing for the features to be tested in this test plan. The subsections are a bit arbitrary. The following is just a suggestion. Section 2.1Unit Testing This subsection discusses unit testing plan. Section 2.1.1Definition This subsection discusses about the definition of the “unit” to be tested (e.g. what is considered to be a unit in the context of the software under test). It also identifies the techniques to be used to judge the comprehensiveness of the testing (e.g. using equivalence partitioning to generate the tests or covering “every statement” in the program at least once). It also specifies any completion criteria (e.g. number of failures observer, number of faults found) to stop / exit the required testing. Section 2.1.2Overview of Items to be Tested Item to be tested Test Description Test Date Responsibility For each unit to be tested, you need to create a subsection to document the test plan for testing each individual unit. The following is a suggestion. Section 2.1.3Unit Test Plan for > Test id Input /Parameter Values Expected Output / Returned Value Reason for the test Actual Output / Returned Value Correct (Yes / No) Seriousness of the Error 1 Section 2.1.4Unit Test Plan for > Test id Input /Parameter Values Expected Output / Returned Value Reason for the test Actual Output / Returned Value Correct (Yes / No) Seriousness of the Error 1 Section 2.2Integration Testing This subsection discusses integration testing plan. Section 2.2.1Definition This subsection discusses about the definition of the integration testing (e.g. what “units” should be integrated together as an integrated component to be tested). You also need to justify your decisions of each integration. It also identifies the techniques to be used to judge the comprehensiveness of the testing (e.g. using equivalence partitioning to generate the tests or covering “every statement” in the program at least once, or “every possible combination” of the interactions between the units to be integrated). It also specifies any completion criteria (e.g. number of failures observer, number of faults found) to stop / exit the required testing. Section 2.2.2Overview of Items to be Tested Item to be tested Test Description Test Date Responsibility For each “integrated” component to be tested, you need to create a subsection to document the test plan for testing each individual component. The following is a suggestion. Section 2.2.3Integration Test Plan for > Test id Input /Parameter Values Expected Output / Returned Value Reason for the test Actual Output / Returned Value Correct (Yes / No) Seriousness of the Error 1 Section 2.2.4Integration Test Plan for > Test id Input /Parameter Values Expected Output / Returned Value Reason for the test Actual Output / Returned Value Correct (Yes / No) Seriousness of the Error 1 Section 2.3Functional (System) Testing This subsection discusses the functional testing plan for different features to be tested in this test plan. Section 2.3.1Definition This subsection discusses about the definition of the system testing. It also identifies the techniques to be used to judge the comprehensiveness of the testing (e.g. using equivalence partitioning to generate the tests or covering “every statement” in the program at least once). It also specifies any completion criteria (e.g. number of failures observer, number of faults found) to stop / exit the required testing. Section 2.3.2Overview of Features to be Tested Feature to be tested Test Description Test Date Responsibility For each feature to be tested, you need to create a subsection to document the test plan for testing each feature. The following is a suggestion. Section 2.3.3Functional Test Plan for > Test id Input Values Expected Output Reason for the test Actual Output Correct (Yes / No) Seriousness of the Error 1 Section 2.3.4Functional Test Plan for > Test id Input Values Expected Output Reason for the test Actual Output Correct (Yes / No) Seriousness of the Error 1 Section 2.4Performance Testing (Non-Functional System Testing) This subsection discusses various performance testing strategies adopted in this test plan. Section 2.4.1Definition This subsection discusses about the definitions of various performance testing (e.g. volume test, load test and stress test). It also identifies the techniques to be used to judge the comprehensiveness of the testing (e.g. using equivalence partitioning or boundary value analysis to generate the tests). It also specifies any completion criteria (e.g. number of failures observer, number of faults found) to stop / exit the required testing. Section 2.4.2Overview of “Non-functional” Requirements to be Tested Req. Id. Non-functional Requirements to be tested Test Description Test Date Responsibility Section 2.4.3Volume Testing (Non-Functional System Testing) This subsection discusses about the volume testing of those items specified in Section 2.4.2. (Use one table per item) Table 1 Volume Test Plan of > Test scenario Test environment and setting Expected response time Reason for the test Actual response time Meet expectation (Yes / No) 1 Table 2 Volume Test Plan of > Test scenario Test environment and setting Expected response time Reason for the test Actual response time Meet expectation (Yes / No) 1> Section 2.4.4Load Testing (Non-Functional System Testing) This subsection discusses about the load testing of those items specified in Section 2.4.2. Table 3 Load Test Plan of > Test scenario Test environment and setting Expected response time Reason for the test Actual response time Meet expectation (Yes / No) 1> Section 2.4.5Overall Performance Testing (Non-Functional System Testing) This subsection discusses about the overall performance test (a mix of load and volume test) of those items specified in Section 2.4.2 under different usage scenarios Table 4 Overall Performance Test Plan of > Test scenario Test environment and setting Expected response time Reason for the test Actual response time Meet expectation (Yes / No) 1> Section 3Test scheduling and resource planning This section discusses the schedule of all testing tasks in this test plan and the resource required for each testing task. You need to define any additional test milestones needed, estimate the time required to do each testing task, and specify the schedule for each testing task and test milestone. You also need to document the resource required for each testing task. Furthermore, for each testing resource (e.g. facilities, tools and staff), you need to present a schedule of when you required it. Section 4Test automation and tool selection / adopting The section presents your team’s consideration of exploring, adopting and adapting the automated testing tools. This includes your investigation of the “tools” that are suitable for the testing tasks, evaluation of their suitability and your decisions. For COS80010 assignment purposes, a summary of the results of the investigations should be fine. Detailed investigation report on each tool is left to the individual member’s own research report submission. Section 5Test result collection, evaluation and reporting This section describes how the test results are collected, evaluated and reported. If you are adopting some automation test framework (e.g. JUnits), the discussion may be just easy. However, if you are using some “OS” specific scripts (e.g. “runUnitTest001.bat” in MS Windows), you may need