Yesterday I had a conversation with a senior testmanager about test processes. He was very glad that his (large) company had a defined and structured V-model based test approach. My reaction apparantly wasn't that enthusiastiac, and he asked me why. And I said: "One size kills all". Let me explain that.
When I look at projects, I see a dynamic environment with a lot of uncertainties, change and growing knowledge on what we are developing. One way to deal with that is to introduce a defined test approach. Through this the fuzz becomes more structured and the goal becomes more clear. But sometimes a different approach is more succesful; for instance by allowing the dynamic to exist, to operate closely as a team and to frequently interact with the customer. That way the goal also becomes more clear and the business becomes more aware of what they actually need. For some projects a strcutured test process might be a solution. For other projects that same solution will only makes things worse.
Let us as testers be aware of the fact that one model can never be the solution for all problems. If someone tells you that, then you know (s)he's a liar. Our world, our projects and software development are far too complex for that. And they involve human behaviour too!
I think we should develop mutliple testing models and approaches based on multiple paradigm views, so that we pick a model that fits our situation. Because else we're just fitting the problem to our solution.
Wednesday, 18 March 2009
Monday, 19 January 2009
Our new book on agile testing has been released
Before my last post celebrates it's first anniversary, let me tell you why my blog has been quiet so long. The main reason was that I was busy writing a book, and that all my writing skills were occupied within that process. After all, men aren't that good in multitasking ;-)
At Eurostar, my new book 'Testen2.0. De praktijk van agile testen' has been released. As you can judge on the basis of the title, the book is written in Dutch. If you're interested in an English version, please let me know. Together with my collegue Eric Jimmink I've worked on this since January 2008.
What is the book all about? First, we explain what agile is. So far, there are no books in Dutch what agile really is, so that was a Must Have. Then we explain new values that arise within this new context. James Lyndsay has written an article on that, whioch is incorparated within the book (thanks, James!). We extend these values towards agile testing principles.
The majority of the book is centered around the section 'Agile testing in practice', with topics such as the role of the customer, the Definition of Done, product risk analysis, master test planning, the test process, unit testing, agile test techniques and regression testing. Since Dutch testers are very interested in testing methods, we described how agile testing is related to other methods, such as Scrum, DSDM/Atern, RUP, Risk and Requirements Based Testing and -ofcourse- TMap.
The organisational implementation of agile testing is described as well, including two client side stories. The last section is about the role of the agile tester; how is the role of the traditional testers influenced by this new process.
So far, all the shameless book promotion :-). Please give us feedback!
The book is available at several websites, for instance at Sdu, the publisher: http://www.sdu.nl/catalogus/9789012580618
Thursday, 24 January 2008
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!
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!
Friday, 11 January 2008
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?
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?
Subscribe to:
Posts (Atom)
