Does anyone have a good article or website regarding testplanning?
I need to explain to my Management (especially Software Development) how important the test plan is to the software development process.
Currently, our process calls for the testplan to be a deliverable, immediately following the first draft of the products requirements document. Our testcases aren't due until after we complete our test (we create them and execute them immediately following receipt of the requirements - but frequently have to change them due to last minute requirements changes).
Our company considers the testplan and testcases as "the test plan." They also refuse to put a deadline on final requirements. They can be changed up until product release. I need to show our Management, why its important to have a preliminary testplan, and what information is needed in order to create one.
We are trying to improve our process in this area.
If anyone has any suggestions - I would appreciate it. Thanks.
Well, it isn't easy to advice you on this. It is really sad that some of us (as testers) must fight for stuff that should be so obvious.
It really should be enough if you show how good-working companies handles this in order to convince your managers but I know that it isn't always that easy.
Maybe you can try to convince them by using following books or articles listed beneath. They should have some stuff related to your problem (such as common development and testing models, the importance of requirements, IEEE-standard documents etc).
Software testing in the real world by Edward Kit
Testing computer software by Cem Kaner m.fl
I know that I should have a link to IEEE-examples of test documents (IEEE 829 and 1012) but I couldn't find it. However, in the first book above there are such examples. Maybe that could be enough to convince about what kind of documentation that should be in place.
You can try this IEEE-link anyway and see what you find. http://www.ieee.org/
The links above are picked from my favourit sites that I have mailed before in the topic "QA documents" in this forum. There is also a topic called "Requirements for test requirement" (I think) that can be of interest.
If this isn't enough, maybe you can use financial arguments. How much more expensive will it be if you don't have a good process in place (i.e a process that allows you to create a testplan in the beginning of the project, test cases that can be created early, based on approved requirements etc. etc.)?
Your situation is not uncommon. I've found over the years that the best approach with management who is not interested in using best practices is to paint the picture in terms of budget costs. QA is not a profit center for the business, so pointing out controlable costs to holder of the purse strings is sometimes the only common paying ground you have. Managers DO care about meeting their budget and getting their bonuses.
You may not be able to win this battle, but I strongly recommend you start your homework now for the future ones by tracking any metrics you can including tracking resource hours expended on reworks, scope creep, missed requirements and volume/severity of bugs found within each code drop. Also, if you have access to the info, track how many bugs were opened post implementation, and time invested on those. Your change of winning the argument for process reform will be greater if you have pictures and numbers ready to back your position up.