More roads that lead to Rome

There is a Dutch saying that says "there are more roads that lead to Rome". I'm not sure whether there is some kind of comparable saying in English, but it means that there are more solutions to one problem. You can try a different road and still end at the same place. This counts for testing as well.

Now the last time I was a bit pessimistic on the progress we're making in testing when it comes to driving new roads in the same direction. But last week I was at one of the largest Dutch insurance and health companies and I got really enthusiastic there. I talked to a couple of test managers and discussed my assignment there: writing an agile test policy document for their test organisation. And they liked it. Not just the fact that it's agile but more the fact that there is an option to choose for a different approach in testing. They've seen in practice and experienced themselves that One Size Doesn't Fit All (!). They are happy with new approaches that gives them more options to shift in testing. And maybe, it's because they are test managers is why they are open to change? Might test managers be more open minded and open to change than testers?

I must say that the competence leader at this company is my biggest Sponsor and I think he has done a great job within such a large company. But we can say that companies have been changing for who knows how long - and now testing departments change as well. Openness is created, roads have been paved. Now all we testers have to do is to decide which paved road to take.

Let's go to Rome!

What wonders me most about testing...

In The Netherlands we have a large tradition in software testing. For the past 15 years a numerous kind of books have been published on this topic. There are two major parties that dominate the testing culture in the NL. All current testmethodologies (TMap and TestFrame are the most used) are based on the traditional waterfallmodel of software development (ie the V-model). Now I don't mind that.

But in discussions with testers (such as on the Dutch forum for testers www.testforum.nl) there seems to be only one belief: the fact that structured testing can only be done based on detailed, documented specifications and test execution-after-all-coding-is-done. In my opininion that is only one of the ways that testing can be done. And that for certain contexts this is not the right approach. Because when specs aren't detailed enough, or to fluid or...whatever - the testers start complaining. They become reactive rather than proactive. Current testing (from a traditional view) has no answer for common software development practices. Such as roughly defined specs, an interactive environment and close customer involvement.

And I am wondering: why don't we, as test professionals, have more answers than just one to structured testing?