Functional Test Plan Template Introduction: How to Use This Tool This tool is intended to be used as an aid in creating a functional test plan. An application’s functional test plan defines how functional testing will be completed to ensure that input produces expected outputs. The plan is only one part of a complete application testing strategy. Functional test planning should begin as early as during the application design of the application development. Instructions: Complete the sections relevant to the application to be tested. Remove any sections that are not applicable and delete the instructions and examples (in grey) once complete. Page 1 Info-Tech Research Group [Project Name] Functional Test Plan Author: Created on: Last Modified on: [Insert Name] [Insert Date] [Insert Date] Page 2 Info-Tech Research Group Testing Goals The following are the objectives of functional testing. List the overall functional testing objectives including reasons for performing this type of testing and the expected value. Also, specify when testing will be deemed complete. Example: This application is new and critical, so we must ensure its functional quality. To validate application functionality, ALL the features will be tested to ensure all functions provide the expected output. Testing will be completed over two consecutive days. Functional testing will complete when all features have passed all associated test cases – no exceptions. Team Member Assignments The following resources will be completely or partially dedicated to the testing effort. The roles each will play in the testing phase. List the people that will be executing functional testing and the role(s) each will play. Example: Name High-level Testing Assignments John Test case writing and execution for features ID: 1-10. Mary Results aggregation and metrics calculation. Carlos User documentation. Table 1. Testing Team Member Assignments Name Roles Page 3 Info-Tech Research Group Scope This section details the features that will be included in the functional testing phase(s) and those that will be excluded. Detail the features that will be tested in Table 2 and those that will be excluded in Table 3. Define the scope as specifically as desired (i.e., leave vague or list specific requirements). Table 2. Features Included in Testing Feature ID Name / Description Table 3. Features Not Included in Testing Requirement ID Name / Description Page 4 Info-Tech Research Group Reason for Exclusion Testing Approach & Tools The following approach and tools will be used to test the application. List how functional testing will be carried out. Include details on the standards for developing test cases, the automated tools that will be used (if any), and templates for tracking results. Example: Testing will be executed with the aid of AAA, the automated functional testing tool. Test cases will be developed and maintained in the tool. Template XXX will be used as the template for creating test cases. The templates listed in the table below will be used by the testing team for creating, documenting, and communicating test cases and test results. Table 4. Available Templates and Standards Template Name Purpose Location (file path) The process for receiving the application for testing, and communicating errors to developers, is as follows: Detail how communication will occur between the two teams. Be as specific as possible and include dates/time frames where applicable. Example: The project is using an agile approach with two-week cycles. At the end of each cycle, the application will be moved to the testing environment for functional testing. The testing cycle will be two days long. Results will be recorded using template YYY and faults will be communicated to the development team at the end of the testing cycle using the ZZZ form. Page 5 Info-Tech Research Group Metrics The following information will be collected from test results to develop testing metrics. In the table, list the information that should be recorded for metric calculations. Examples: • Functional Metrics: Number of requirements verified (may be broken down by phase, component, tester, or all of the above). • Problem Metrics: o Problems found per day o Problems found per component • Schedule Metrics: o Percent of tests completed o Estimated days to completion o Time to complete testing by component Table 5. Information Collection Details Metric Purpose Page 6 Info-Tech Research Group Required Information Functional Test Cases The following test cases will be created and executed against the application. Using the template below, complete the details for each test case. Copy the template each time a new test case is created. This section can be moved to a separate document and referenced here. Example: Test Case Field Details Test Case ID: Test Case Name 1: Successful login Purpose Tests that the user can log in with a proper username and password. Initiation Criteria All cookies cleared and user must not be logged in. Execution Steps 1. Navigate to Web site. 2. Enter a valid user name. 3. Enter a valid password. 4. Click enter button. User is logged in to Web site and the main page is displayed with user name in welcome message. Expected Results Table 6. Test Case Template Test Case Field Details Test Case ID: Test Case Name Purpose Initiation Criteria Execution Steps Expected Results Page 7 Info-Tech Research Group Traceability Matrix The traceability matrix relates the test cases to their respective requirement use cases. Not all test cases will have a direct relationship, but all the use cases for the features in the scope should have associated test cases. Include a reference to the completed traceability matrix. _____________________________________________________ Info-Tech Research Group tools and template documents are provided for the free and unrestricted use of subscribers to Info-Tech Research Group services. Use this document either in whole or in part as a basis and guide for document creation. To customize this document with corporate marks and titles, simply replace the Info-Tech Information in the Header and Footer fields of this document. Page 8 Info-Tech Research Group Functional Test Plan for: [Insert Story Description] Applies to stories and Track-Its where code is created or changed. Label and attach any supporting details or artifacts. Version: [Version] Track It or SCRUM Tracker # Prepared By Date Overall Test Result: ▪ ▪ ▪ ▪ Stakeholder Approval Signature / Date Signature acknowledges change has been tested by the stakeholder or user, and is approved to migrate to CRE/production. Pass Team: , Scenario Tester: , Test Date: Test Scenario Objective #1: Assumptions: Dependencies/Contingencies: Test Files/Data, if relevant: Sandbox/Server tested on: Step Procedure/Description Fail , Test Time: Expected Result Actual Result Pass/Fail 1. 2. 3. 4. 5. _______________________________________ Developer Approval Signature ▪ ▪ ▪ ▪ Team: , Scenario Tester: , Test Date: Test Scenario Objective #2: Assumptions: Dependencies/Contingencies: Test Files/Data, if relevant: Sandbox/Server tested on: Step Procedure/Description , Test Time: Expected Result Actual Result Pass/Fail 1. 2. 3. 4. 5. _______________________________________ Developer Approval Signature ▪ ▪ ▪ ▪ Team: , Scenario Tester: , Test Date: Test Scenario Objective #3: Assumptions: Dependencies/Contingencies: Test Files/Data, if relevant: Sandbox/Server tested on: Step Procedure/Description , Test Time: Expected Result 1. 2. 3. 4. 5. _______________________________________ Developer Approval Signature ▪ Comments/Notes: Last Updated: 09/08/2009 -1- Actual Result Pass/Fail
Purchase answer to see full attachment