I was reminded on a lesson I've learned earlier in my testing by something that happened today.
Towards the end of the working day, I noticed a bug report being just now marked resolved. With my new found powers (I control the builds for myself, finally!) I was keen to test the fix right away. I checked the comments to find out that no fix had been made. Instead, there was a comment telling that this is related to a behavior in the program we plan on fixing later, and actually is exactly the same problem.
I talked briefly with the project manager, who knows the product in nice detail, and he almost convinced me that the symptoms I had reported could be related to that. I asked quite many question to clarify how the feature should work if this was indeed the explanation to what I was experiencing. Joking over the low wall of my cubicle, I told him that he must know I will not take his word for it, but I will need to see it by testing it. I felt that was probably a thing for me to experience. And perhaps I could notice something else while checking that - it has been a while since I've looked at that particular scenario.
I decided on the minimum test that I would need to do to find out if it works as specified for now even if it doesn't work as we'd like it to work in the long run. And, also a little to my surprise, I learned that while they had been looking at component A, the problems causing the symptoms were likely to be in component B and the problem was real. I was able to add better isolated steps and explanation to the issue.
What this little piece reminded me is:
Follow through the stuff, even in cases where the explanation sounds plausible, theory is just not the same as trying things first hand.
The style of discussion with the project manager was also very positive. He never suggested I might be wasting my time. We both smiled and joked about it, both before and after. And we felt a common sense of accomplishment now that we understand that just a little better and know where to dig in to find the thing we need to fix.
Towards the end of the working day, I noticed a bug report being just now marked resolved. With my new found powers (I control the builds for myself, finally!) I was keen to test the fix right away. I checked the comments to find out that no fix had been made. Instead, there was a comment telling that this is related to a behavior in the program we plan on fixing later, and actually is exactly the same problem.
I talked briefly with the project manager, who knows the product in nice detail, and he almost convinced me that the symptoms I had reported could be related to that. I asked quite many question to clarify how the feature should work if this was indeed the explanation to what I was experiencing. Joking over the low wall of my cubicle, I told him that he must know I will not take his word for it, but I will need to see it by testing it. I felt that was probably a thing for me to experience. And perhaps I could notice something else while checking that - it has been a while since I've looked at that particular scenario.
I decided on the minimum test that I would need to do to find out if it works as specified for now even if it doesn't work as we'd like it to work in the long run. And, also a little to my surprise, I learned that while they had been looking at component A, the problems causing the symptoms were likely to be in component B and the problem was real. I was able to add better isolated steps and explanation to the issue.
What this little piece reminded me is:
Follow through the stuff, even in cases where the explanation sounds plausible, theory is just not the same as trying things first hand.
The style of discussion with the project manager was also very positive. He never suggested I might be wasting my time. We both smiled and joked about it, both before and after. And we felt a common sense of accomplishment now that we understand that just a little better and know where to dig in to find the thing we need to fix.
