Back in “ye old days” where I worked in an Waterfall environment when you could be designated tester on project ABC, there was always a requirement on a per project basis to write up a comprehensive test strategy document. As well as detailing the specific tests that would be executed, it would outline things things like:
- overall approach
- browser coverage
- what was out of scope(based on test case prioritisation of high, medium, low)
So in the example of project ABC which was estimated at 3 months one of the first tasks before starting the execution would be to write up this document and send it out for review to the various stakeholders on the project. This could sometimes take a couple of days to write, which wasn’t an issue when working on such a big project as there would be time to do it.
In an agile world where we are working in sprints of 2 weeks, where there are multiple projects(or user stories as they are known at our company), these are a lot smaller in size but if we wrote up test strategy documents for each project we’d spend the whole iteration on documentation.
Again, this is something I’ve thought about for a while and would appreciate peoples thoughts on some of the questions I have and maybe give some examples/pointers
- is a “per project” test strategy document the right approach in an agile environment?
- would an global test strategy document be the right approach which is more of a static company wide test strategy document, acting more as governance, as apposed to doing this for each project?
- is a test strategy document even necessary at all?
I’ve had some great feedback during my short time on this site so looking forward to seeing what people come back with