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.
WebSphere Commerce 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 into different severities 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.