The verification and validation test plan portion of a business analysis describes how a software product will be tested. Make sure to include the following sections in your verification and validation plan.
Start off by explaining the test and describing the objective of the project. Remember to keep it short. Make sure to include any references to other documents here.
Define the items that you’re going to test. They may be the requirements documentation or design documentation. Your company may have different names for these documents, but no matter their names, what you test comes out of these documents.
Features to be tested
List the software features you’re going to test. As you think about this list, think about the data you need in order to test.
Features not to be tested
Including features you aren’t going to test seems counterintuitive in a testing document, but doing so immediately sets up appropriate expectations; users won’t have any misconceptions about what they’ll have tested.
Test data necessary
You have to figure out not only what tests you need to run but also what data needs to be in place for the test. Remember: A test has planned inputs, so you need to think about what the expected results are based on those inputs.
Here you explain the approach the testing team is going to use to verify the requirements. It states any testing cycles and tools, manual and automatic.
Item pass/fail criteria
Have a clear definition of what makes a test case pass and what makes it fail. Defining this guideline upfront in the validation and verification plan can prevent confusion later.
Suspension and resumption criteria
This section of the plan details how you handle defects in your testing process, such as the fact that you’ll stop the testing if a test procedure can’t be run and resume when a new software build is provided.
The section is a listing of what tasks, such as defining testing schedules and creating test cases, need to be completed in order to carry out the testing. The results of the testing tasks will be the test plan, test design specifications, test cases, test procedures, test logs, test results, and defect logs.
Here, you detail the specific environment in which the test is to be conducted to show how the solution works in the environment. Look to the nonfunctional requirements to determine test needs such as volume test, stress test, configuration test, and so on.
Knowing where the tests are conducted is important to developing the test plan. You want to consider these questions:
Is the test in a lab? What are the lab conditions?
Do any special environmental concerns affect the test? Can you simulate them if they’re not in the actual test area?
Are the tests in a central area accessible to the testers, or do testers have to travel to test the system?
Document your findings in the test plan so everyone who is involved in the test knows the location and can plan appropriately.
Who performs which set of tasks? You need to understand who’s involved in testing so you can plan appropriately for the test. Here are some questions and concerns to explore:
What kind of experience do the testers have with the project?
What kind of experience do they have with the system?
Do they need to be trained prior to testing? If so, you know you need to add time into the project plan.
Are the testers independent? If not, can they avoid making assumptions (which is a risk because they built the system)?
Do they have testing criteria? Are they looking to you to create testing scenarios and test cases?
Are they located on-site? Are they traveling? How does that travel affect the project plan?
What time commitments do they have outside of the project? Is it 10 percent or 50 percent?
If you’re managing other business analysts and need to move some of your people around, testing is one of the best times to do so.
Staffing and training needs
If the testers need to be trained on the system or if you need additional staff or have to requisition staff from the QA pool, you include that information here.
Talk about the dates for the tests, as well as any testing cycles and when they may take place. If this information is detailed in a project plan, you may want to just include a hyperlink or reference to the project plan to avoid getting dates out of sync.
Whenever you have a chance to, you should provide one source for the information. The more you manually document the same information in multiple places, the greater chance that when updates happen, one of those documents will be out of sync with the rest.
Risks and contingencies
Outline any risks associated with the test and include any contingencies that address them. Similar to the schedule, if these testing risks are located in a different document, referencing that document here is fine.
By understanding the degree of risk in the various areas of a solution, you’re in a much better position to understand where to spend your testing energy. If time becomes an issue, knowing what your highest-risk testing areas are allows you to focus on them to make sure you get the most return on your testing investment.
The people who sign off on the verification and validation plan are those involved in proving functionality and validating suitability. Those performing the tests sign off and in doing so indicate that they’re aware of what is in scope for the tests. Those accepting the system (clients and customer) may need to sign off, as well, indicating awareness of what will be and will not be tested.