We are currently preparing our testing department for a new release of our latest project. We would obviously like them to follow a thorough plan for testing our software and insuring that bugs are passed back to us (the development team) before release.
Are there any good tools or methodologies to follow in creating this test plan?
The best book I've found on the subject is Managing the Testing Process. The author goes into how to create a test plan.
In my experience, the basics of a test plan are as follows:
If you can fill that out, the team should be able to carry out testing pretty well.
One decision you need to make is how capable is the test team? I prefer a test plan to be an algorithm to derive all of the test cases. Describe the sorts of cases, but not necessarily each case in detail. If the team is less competent, you may need to spell out each case specifically.
One final caution. Avoid the siren's call of being too detailed. A plan that cannot be kept in someone's head is not likely to be followed. If your test plan is 25 pages long, you probably wrote too much.
And let's not forget, there will never be enough time to do all the testing you want to do. So the tests in your plan will need to be prioritized. I often find that prioritizing by risk is the best way to go.
However, usually a test plan would be developed by the QA group, in coordination with dev and PM. If QA is not creating the plan on their own, it sounds like your QA team could use an upgrade. At the very least, even if dev is putting together the initial plan, QA should provide some input, as they will have a different POV. The more eyes on the test plan, the more complete it will be.
Unit and integration testing should catch a lot of the problems at the code level, but they aren't great for testing how the system behaves from the user's point of view.
Once you know what a feature is supposed to do and how to know whether it works or not, automate that test (where it makes sense, obviously) using something like TestComplete, Smarty Script or something similar. These tests are easy to run, so there won't be any shortcuts in testing, and they will always run consistently.
QA should absolutely be writing the test plan, as Tom E points out. They should engage with the customer to understand requirements and with the dev team to understand implementation, but at the end of the day the team with the testing mind set needs to own the test plan.
The only situation I can think of where a test plan might need to be written for a QA team is when you have an outsourced team doing QA who is not yet familiar with your product. In that case, I'd recommend having one or two senior members of the team colocate with you during design and development; it helps them come up to speed much faster and they can pass on that knowledge to the rest of the team.
hey pavliks, i dont know how basic you want it, but if you want something simplistic and easy to pick-up and run with, have a look at this article: Writing a System Test Plans
if you know your software well, have MS Word installed, and have good documentation skills, you are good to go
in terms of a very basic, generic bug logging protocol to go with it, you can have a look at: Logging Bugs Like a Pro <- this is all about logging bugs with minimal effort and capturing the bare information needed to investigate a bug
-- LM