Recently I was in a discussion with a tester/user who wanted more information about the cause of an error and the provided solution. It took quite some time to understand each other. I have to say that I made a huge mistake here. I listen to the tester why he needed more detailed information only draw the wrong conclusion.
Although I know it is not covering everything, I think it still can be used to visualize our thoughts.
The conclusion was merely: Why do you need all that information if you can check if the symptom is solved, it is a minor change and has minimal impact on your process. Demanding more information although no agreements with development are made to provide this will extend the cost of the solution.
Basically the problem was not the level of detail of the documentation and the provided solution. The tester just wanted to know if the developer understood his problem enough and wanted to check until which level the analysis was done.
It took more time to understand each other: the tester wanted more information so he could decide the impact and define the test depth. I tried to convince him that if there is less chance of damage, it might not me wortth to go into this detail.
This made me think how we could talk the same language. for this I created a picture, perhaps this will help in the nearby future to discuss.
The first picture is to identify the type of error and how it is solved. The columns at the end can be used together with the developer to get a mutual understanding about the error, cause and the solution.
The second picture can be used to visualize the questions we might ask and to monitor if the effort for gaining information is worth in relation with the solution and impact. I also left here the possible questions as they have to be defined in their context.
Although I know it is not covering everything, I think it still can be used to visualize our thoughts.
No comments:
Post a Comment