Hi, in this video let's look at what goes into a test plan. First, a review of the stages and the test plans it creates. Unit testing is where the developer tests their own code, primarily for error prone constructs and very low level functionality assurance. A unit testing plan is generated. In practice, this isn't always a formal document. It's likely a plan put in place by the developer while they're working on the project. The plan is, in essence, the tests that are created by the developer. Design verification testing covers the integration of modules through integration testing done by the developers, and functional testing, completed either by the developers or the testing team. A system validation test is a test team task. Once the system is finished, or nearly finished development, the system is tested for high level behavior and non-functional performance. Out of these twos stages come the DVT and SVT test plans, or sometimes one comprehensive system testing plan. That encompasses the verification level understanding of how we ensure we've built the thing right. Finally, customer acceptance involves the testing team and the customer, ensuring that the final product is, or will be, acceptable to the customer. This testing plan determines whether or not we built the right thing, that is, the customer actually wants it. So what does one of these things look like? Well, it's rather ancient, at least in tech terms. In fact, it is based off a standard built in 1998. However, many organizations still adhere to the IEEE standard. This is so that external or internal reviewers have a set understanding. They know what they're looking at, and they know what they're looking for when reading a document of this kind. But this is just one recommendation for building a test plan. So let's take a look at some sections that should be in any test plan, whether they follow the standard or not. The highlighted items here are the four important components, according to the Quality Assurance Institute. Scope means know your domain. There's no way to properly define your tests without knowing the bounds and the domain within which your project works. The schedule. I like to include the original schedule and the actual or current schedule. A statement like we will be done ten weeks after the final build is perfectly acceptable. Resources. People, materials, consumables, equipment, servers, time, testing tools, all of that's important. Who is the domain expert? Who's the technological whiz? Who's the testing guru? Identifying these people and resources is going to be very important, especially when it comes to the management of the testing process. Entry and exit criteria. Hopefully, these come right out of our process so there is never anything new here. It just puts it in front of management and development one more time. We are not the starting testing unless, or if we find five defects, we stop. That is, if we find too many defects, we hand it back to development for further unit testing before we really start our own work. The requirements matrix, with test cases for traceability, is also an important aspect here. It's something else that we'll come back to. According to the requirements, our 9,000 system could have up to four color modules in one system. But we never tested it. Sometimes requirements are not in alignment with the customer's needs, despite what marketing says. These are all things that have to be incorporated into your test plan. Our requirements currently are in XML format. So much for the sentence structure of an SRS. And, hence, can be parsed and compared to a specific field in our automated tests. Thus, we can get a traceablilty report if we trace our test cases to requirements. The point of the second type is to know which test to rerun when a requirement changes, as well as whether all requirements are getting tested. We have a tool to tell us this, at least at the test level. That's why we have that XML formatting. Our TMS tool inverts, tracing test cases back to requirements, to get tracing requirements down to test cases. But whatever you decide for traceability, how traceability is done must be part of the test plan. Either in a requirements matrix, the test cases document, or a completely separate section in the test plan. The most important aspect of having a plan is following it. Again, this is a measure of rigor, being introduced to this endeavor to attempt to ensure quality through a controlled and guided process. It only works if you have it and you follow it. Be sure that you include what cannot be tested. And we'll talk about including what was not tested when you make a report of your testing. And it's going to be a living document. Things change, and that's most certainly true in testing.