Tuesday, June 2, 2009

There are methods for almost everything you can think of, also in the field of software testing. What often is forgotten is that a method is just a representation and simplification of reality. The danger I see is using methods without questioning that method. Without knowing and checking the boundaries of a method you make unwillingly the assumption that the situation you are in is exactly as the method represents.

I hope you agree that nothing can be identically as described in the method you are tending to use. If you think so you have not only to search for the boundaries for the method you are trying to use and implement, you also have to investigate your own situation much better.

Often I see that people are familiar with methods they have been taught. Over the years they implemented and relied on them, they created some best practices for themselves. In the beginning they asked other people if they understand it correct and used it right. At that moment they were questioning themselves, the method and the environment they were into. After a while it became just a trick they performed and implemented methods the easy way, not questioning anything. I see this as a risk using methods you know. You are no longer fitting the method to the organisation; you are trying to change the organisation to fit the method so you can be successful.

At school I bothered the teachers with asking questions about the method, claiming that those are not useful. Looking back I questioned the method to understand how it works and where the boundaries are. This made me help to implement and use it when possible and triggered me when I tending to cross those borders when implementing them.

It is easy to say that a certain method is not useful; it is harder to tell what parts can be useful and what parts can be of advantage for you.

I suggest that instead of starting with methods or best practices, first start asking questions to get a picture of an organization/ project. Based on this you might be able to create a model for your own of that organization/project. Now you have two models, one model of the organisation and that one called method. Combining this with the known boundaries of the method you might be able to successfully use the method or parts of the method and become successful yourselves.

AS IS

The postings on this blog are provided "AS IS" by Jeroen Rosink with no warranties. Most of the post will be thoughts, and thoughts can change over the time. I would appreciate when you leave a comment to sharpen my ideas and thoughts.