Useful strategy documents - part 3.
Next project's strategy document is test strategy.
"It depends on" Have you ever heard it? Of course yes. The content of a test strategy document is one best example for this type of answer sentence. Why I am saying it? Think on it a little bit. You could be one of the best test manager, tester, testing software user, your are doing the best job during software testing and your project could'nt be a success story if your project hasn't got this informations well defined and approved(!) by the customer:
- Project scope
- Acceptance/goal criterias
- System requirements
- High level use cases
- Architectures (hardware/software or business/data/application/technology)
Why are they important for us? Because they are the elementary input information for a succesful testing. If you are lucky and your customer or your company already implemented one of the architecture frameworks (TOGAF, Zachman etc) and reached the planning step (for example in TOGAF the F. Migration Planning step) than they are already well documented and accesible before your implementation project started. If not it doesn't mean that they are not available, hopefully your project team already realized they necessarity and created them during the project's progress.
So first let's go through them, then I will try to mention a skeleten for the test strategy document.
