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?
What managers do with V-model Testing
it's still current practice...
About Me
- Agile Tester
- I am a software tester since 1997 and involved in agile software development since 2001. I keep wondering why these worlds seem so much apart, while actually they have a lot in common.
3 comments:
Hi Anko, I think there more than one truth out there to this - as you know I do. Agile and iterative development methodologies all embrace the idea that testing is a vivid part of each of the iteration. During each iteration a number of (similar) work items are produced, such as (smart) use cases or features.
In fact, testing already takes place before code has been written. We, for instance, test our smart use cases using a similar technique as TMap proposes in process cycle tests. But, here we test based on minimal use case description - and as a part of getting concious about the requirements for our use cases.
This presents our testers with a totally different role in projects - being the prmary designer for the project that is. Hence we approach testing not based on fully specified documentation (whatever that is, and whenever it's produced - mostly never) but testers play an important role in our projects.
Having the illusion that testing should only be done on fully qualified documentation places testers in a very dependent position at the end of a project, and often in a very destructive role, as you are about to bash on the work of all other team members...
Agree, and I know we are both agile believers. Being *really* involved upfront is a major paradigm shift for testers but for me it's the only way to go. For so long we testers have been whining about the fact that we wanted to be involved early. In agile projects there is this great opportunity - and then we whine about the fact that it isn't as we expected. And testing *should* contribute to the design, like test guru Boris Beizer said "The design isn't done until the test cases are ready".
By the way, from an agile perspective this quote would be: "The design isn't done until code and test are ready" ;-)
The Dutch testing world needs somebody who spreads the word about agile testing.
I think that person is you, Agile tester
Post a Comment