Death to Test Strategies

I read a post the other day on LinkedIn which talked about the criticality of having a good test strategy. Before I get castigated online, I agree. I agree that for every successful product being built, the team needs to have consciously thought about its approach to testing.

The mere fact of thinking about what you are going to test (ie. the product) and how you are going to test it forces you to think about what you are building in a number of different ways. It will unearth elements not thought of before and raise questions not asked. Not to mention provide everyone with the same vision of approach, which can lead to questioning and challenging (in a good way).

My problem with a test strategy is the test bit. Testing and Development are so intrinsically linked that you cannot have one without the other. The mere fact of compiling and building a unit of code is a form of testing. Nobody writes code and does not do this - well unless you are crazy (and granted there are some crazies out there). So why would it ever make sense to write a completely separate development & testing strategy. Why can't we just have a strategy?

This is what we are developing & testing.

This is how we are going to develop it.

This is how we are going to test it.

Why does it need a whole raft of information on System Testing in it? Why does it need a distinct phase for Acceptance Testing in it? Why does it need System Integration Testing phases in it? Yeah yeah ok, in waterfall maybe - but who really does that any more? Maybe wagile.. or maybe some waterfall nuclear thingy, which, thank you very much I will never be involved in.

The way I see it, we need to ensure we cover functional elements and non functional elements in our testing. It all falls into that. The most descriptive test strategy I have seen lately is a one page picture (which is on this post and forgive me, but I cannot remember where I got it from, so can't give the credit where it is due), which we can enhance slightly to include the development side.

"Oh we need to be objective" you say.. can a team of professionals not be objective in one document? In fact, a document which is a collaboration should help increase objectivity if the entire team is reading, reviewing and contributing to it. 

So, here is my hope to that I have written the last Test Strategy I will ever write. I know that will not be the case because unfortunately, quality is in many cases an afterthought. Quality is really only noticed in the absence of it. However, working together as a team we can change that to be the first thing we think about.