Foremost is ” why” component before the ” what” component. The test strategy should not only state what it is going to achieve but also why it is going to achieve it. This way other stakeholders have a buy in.

A ” Strategy document” is at a higher level of the management with a dashboard full of metrics.

I have one question and one challenge.

The question is “Are you eliding the difference between a test strategy and a test strategy document?”

You might indeed have five good reasons to have a documented test strategy. The challenge is this: go through each one of those reasons, and add “unless…” to it, and see where that takes you. For extra points, do that three times for each reason. The difference between the unqualified and the qualified reasons is the difference between best-practice thinking and context-driven thinking. The former makes no particular distinctions between good (or useful, or timely, or cost-effective) test strategy documents and bad (or useless, or archaic, or overly expensive) ones. The latter helps to determine the conditions under which you might wish to document your test strategy, the different ways in which you might choose to do it, the amount of time you spend on it, the amount of effort you spend on it, the different audiences for which you might want to produce it, etc. etc.

Cheers,

—Michael B.

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=69657630&gid=55636&commentID=56040215&trk=view_disc&ut=3RmdisliCuBkY1

regards,

Will

I saw recently some test tool for Erlang I believe that takes an automated test and does exactly this, re-runs the test several times till finding the minimal set of steps that reproduces the error.

So while this approach is more effective for automated testing, it should also be a part of a tester’s checklist when following manual test cases or exploratory testing.

After spending around 8 years in testing I found that each tester has its own perception about testing or I would say each tester has different perception about requirements, about test scenarios, test scripts, writing defects, defending their defects and even they carry some kind of perception about developers as well.

Most of people are running towards Quantity instead of Quality.