It is now almost a week ago I had a challenge with Matt Heusser. One of the interesting things I learned is that approaches differ on some points. Over the years I was thought to think in processes like TMap, ISTQB , ITIL, PRINCE2. A good habit of mine is to investigate the borders of those methods.
When I was at school I noticed I drove my teachers and also fellow students crazy when questioning methods. Not to proof they will not work or they are not true. Just to investigate the boundaries of methods with the purpose to know when I cross those boundaries I need to be creative.
During the challenge I forced myself to set aside what I learned and re-shape my knowledge based on the questions I got. This helped me to find some answers and missing others. Of course this is not bad. Only there was on obvious test I forgot. Knowing it is an obvious one I forced myself thinking and start using all kinds of methods approaches etc. I noticed this brought me further from the actual solution. at the end I mentioned it, only as a side note and not as main thing. you might say I was a bit blinded by methods.
I learned that obvious things are often missed.
In the projects I worked in methods were pre-defined. In the Netherlands a method like TMap is very common. It helps you to create a structure in the test process. In almost every project it becomes a main goal to work according this method as it is already sold to create structure. When other actions are needed it is first checked against the method, does it fit in. Sometimes the approach is changed; sometimes the actions are not done because it was not agreed upon and needed as the test plan is leading. This lead to actions are skipped based on "false" arguments.
This brings me back to a phrase a teacher told me once: "Methods are tools to model your situation, keep in mind that models are just a simplification of the reality"
Based on this statement, methods and defined processes as result from methods are fallible. You never can capture reality in a model. You will always miss items. Only afterwards you might notice the importance of missed items.
When obvious things are missed based on using methods and following processes. Then, thinking in methods and processes lead to obvious blindness. The question is how huge wil this obvious blindness be? I'm sure a lot of methodologists are claiming this is untrue. There is space in methods/processes to prevent blindness. Perhaps it is. Only is this for everyone?
If everything can be dealt with by a method what level of experience and skill does one need about that method to prevent the obvious blindness? And is it acceptable to demand those level of skills to anyone? Is this reality?
A new question is: Are we dealing with reality or methods?
What would you do?
1. Accept obvious blindness and deal with it later when it fits the methods/process
2. Reject methods/processes and define your own world
3. Define space in methods/processes to address time to investigate obvious blindness holes
4. Teach project members in methods to the highest detail and claim there cannot be any obvious things which are not overseen
Saturday, July 25, 2009
Bounded by thinking in methods and processes
Posted by Jeroen Rosink at 9:48 AM
Labels: Test Methods, Testing in General
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment