In order to create a valid and clear test plan, you need to have a grasp on what you are testing. I’m lucky in that I have well written requirements documents, development plans, and management plans available to me when I write my test plans. The ability to see the whole scope of the project while I’m writing is invaluable to the finished product that I end up with. For some projects a wireframe is included, which helps determine navigation tests that can be done before seeing the site layout.
Feature Tests
These are also known as Design verification or Compliance tests. Requirement definitions should be split up into different feature sets. Each of the different features has its own subset of requirements that are desired at project completion. Your test plan should include not only the happy path for each of these features, but also the failure paths for each.
I usually start out by title listing each of the tests I’m going to perform. This helps me keep my train of thought on the feature and not on the test itself (That comes later). I try to keep my test titles general to start with, this way I don’t beat my head over one feature trying to think of that next test, usually the act of writing the case will make you think about more tests to run.
You should include each of the following types of tests for each feature in your project. Keep in mind that some of these types will only be applicable for certain features and certain projects.
- Functionality
- Load
- Performance
- Database
- Security
This is a very general list, and some of the types mix well with different tests, but you need to take into account the different types of tests when determining what tests you need to run. Remember that you’re writing a test plan, not a test case. More detail can come later, get the idea out of your head and on paper. Step it out later.
Integration Tests
These tests take a bit more imagination to come up with and require greater knowledge in the underlying system than feature tests require. As such, they are more involved to come up with, write, and deploy. They also use a broder spectrum of the test types I detailed above. If you have wireframes available to you, you should be able to spot the areas where the features are going to be working with each other or even just co-existing. Start writing from that point.
Integration tests verify that each of the features designed work with each other and don’t break each other. Also if the project you’re working on is an add-on to a larger software project, this will also be the testing ground for other features, but that’s a different kind of test.
Regression Tests
Regression tests are for projects having changes done to them. If it worked before the project it should work the same way after. With each test plan you need to go through the current set of regression cases and find the ones that need review because this project’s scope will change their functionality. This doesn’t happen with every project, knowing the in’s and out’s of the underlying software project will help you determine if the test needs rewriting.
You also need to go through and mark some of the tests that you’re planning on writing as a regression test. These are usually the main happy path test cases as well as a few failure cases. Try to get away from adding each of the feature test cases to the regression plan though, otherwise the first paragraph in this section becomes a much longer-lasting task. You want to be sure that your regression plan has coverage over each of the features in your project, but not too detailed where every release requires maintenance of a large percentage of test cases.
Acceptance Testing
In regards to projects that involve a client, they will usually have a testing time period of their own to review the product and make sure that they are getting what they paid for. Don’t be surprised if changes to each of the documents that you based your test plan off of are modified in different areas. Also, have a conversation with your project manager prior to this step of the testing process. Most clients are going to claim everything they find wrong with the project is a bug, when in fact it might be a change of scope, or an ‘as designed’ feature. This is common, expect it.
Keep in mind
Always make sure to keep an open communication channel with the development and project management staff regarding changes to any of the documents. Before starting your test plan, always check to be sure that you have access to the latest version of the doc. Once you finish your test plan, you can start writing your test cases, but I would suggest verifying again that the docs you have are the most up to date. Yeah, I know you just checked, but these are living documents, they’re going to change. This will save a lot of headaches in the future.
–dez
