High-level functional verification test plan
The high-level functional verification test (FVT) plan, a
document that is written at the beginning of the test cycle, is an agreement
between the development team, project management team, and the FVT team on test
coverage and scope. The document is reviewed and approved by stakeholders before
the beginning of functional verification testing. Use the high-level function
verification test plan template as a basis for creating your own test
plan.
Test types
The high-level FVT plan template describes,
or refers to, the following test types:
- Access control test
- A type of test to verify that only the authorized roles can perform actions on authorized business objects.
- Accessibility test
- A type of test to verify that users who have a physical disability, such as a visual impairment, hearing impairment, or limited mobility, can successfully use the store.
- Exploratory or ad hoc test
- A part of functional verification testing that is performed without planning or documentation. The tests are run once and are performed to identify unexpected errors in the project. If an unexpected error is discovered, additional exploratory testing is performed.
- Full regression test
- A type of test to verify that most functional flows work correctly. A regression test depends on what code was changed and the importance of the functionality.
- Functional scenario test
- A type of test that verifies the use cases functions as described in the use case document; it includes main path testing, error handling testing, and exceptional flow testing. Functional scenario testing is a main part of FVT coverage.
- Functional verification test (FVT)
- A type of test that uses the solution specification document, design documents, and use case documents to validate that the software is functioning properly.
- Globalization verification test (GVT)
- A type of test to ensure that features can handle international support without breaking functionality. GVT ensures proper functionality of the features with all supported languages, cultures, and locale settings.
- Large-scale data test
- A type of test to verify that the system continues to function correctly when many business objects are present.
- Regression test
- A type of test to verify that code is checked in, defects are fixed, and that existing code does not regress.
- Sanity test
- A type of test to verify that major functionality is working correctly. To ensure that critical paths are tested quickly, a small subset of test cases are selected.
High Level Functional Verification Test Plan sections
The sections in the Functional Verification test plan are:
- Objective
- Sets the overall goals for this FVT test phase. The remainder of the test plan is built based on the goals that are described here.
- Use case coverage
- References the use cases that are supported in the project. The Use Case Document is a separate document that is maintained by the development architect or by the development team. Use case coverage details the coverage of the use cases and any special test considerations that are required for any use case.
- Assumptions
- Describes any assumptions that are made for FVT. Assumptions must be clearly
written and thoroughly reviewed by the stakeholders and reviewers to ensure that
there are no gaps in test coverage.
If there are any assumptions that are applicable only to a specific test case, list the assumptions in the Functional Verification Test Case Document.
- Functional verification test scope
- Defines the scope and coverage for the FVT phase. The document describes what types of test cases are covered by the FVT team and the areas of FVT responsibilities. To minimize the risk of gaps in the test scope, ensure that Functional verification test scope is reviewed and approved by stakeholders. The test plan template contains examples of what to complete here.
- Test methodology
- Describes the how of FVT. Test
methodology includes but is not limited to:
- The entry criteria (essential requirements to start functional testing) and exit criteria (essential requirements to finish functional testing) for each phase of FVT.
- The process to follow if the entry or exit conditions cannot be met.
- The process, or guidelines, to select acceptance, sanity, and regression test cases.
- Details of the events that trigger regression execution.
- Frequency of planned regression execution phases.
- Test tools to be used during testing, including automation, tracking, and defect management.
- Environments tested
- References the server environment and client environments. (A server
environment is where the functional development binary code resides. A client
environment is the environment that is used by testers.) Support statements,
such as browser and operating system support, are made before the beginning of
any tests. If there are environment diagrams available, reference or copy the
diagrams into the Environments tested section.
Describe client-side configurations that are tested, such as browser and operating system configurations, in this section. Any risks that are taken in this coverage must be detailed to ensure that they are acceptable to the stakeholders and reviewers.
Document any server-side configurations or client environments that are used by the test team including any simulators.
- Exclusions
- Describes the Areas that are normally covered by FVT, but excluded from FVT in this project. Add a corresponding risk assessment and mitigation for these exclusions.
- Dependencies
- The dependencies FVT has on other individuals and other teams. Clearly describe:
- Who is dependent on whom
- Deadline for the dependency (a date or a milestone)
- Potential risks or impacts on the schedule if the dependency is missed
- Responsibilities
- Lists test roles and their responsibilities. If available, list FVT test team members and their roles in the project.
- Schedule
- The high-level FVT schedule. The schedule can change over the course of the project. The schedule is tracked and maintained by the project manager or FVT test lead; therefore Schedule is not regularly updated. The Schedule section is intended as an effort estimate to ensure that the FVT team has sufficient time that is allocated for testing given the scope, coverage, and resources.
- Risks management
- Describes any identified risks and how to track and mitigate the risks. Describe the deviation process to explain how deviations from this test plan are identified and handled.
- Status tracking mechanism
- Describes the FVT status tracking mechanism and the tracking tools that are used. A sample status report helps to set the expectations of the stakeholders on what they can expect throughout the project.
- Test resources
- Lists and describes all of the resources that are used by the FVT team during the FVT phase including people, hardware, software, or tools. If available, specify the total number of testers required and the names of the testers.
- Defect management for functional test activities
- Defines:
- What is considered a defect.
- How defects are categorized by severity and a definition for each severity.
- How defects are categorized into different priorities and a definition for each priority.
- The defect lifecycle.
- The expected defect turnaround times.
Lists the tools that are used to store, track, and handle defects.