I often use car analogies to describe software testing. Another case for this happened to me today, and it exactly matches this scenario. Imagine you are driving your car and hear a noise – you want to take it to the shop to get it fixed, right? It’s the same with bugs – the application starts to "do something fuynny," so you file a report and grab a developer (mechanic) to fix the product.
Of course, if your luck is like mine, by the time you get your car to the shop the noise abates. Sure, the mechanic will come out and take a look, but since everything is fine, there is not much to be done. So you drive away without the underlying problem fixed.,
Last month we moved our test team notebook to a new Sharepoint server. And from day 1, I could not log in. I gathered Fiddler traces, examined other logs and could not pinpoint the error. I finally managed to get in touch with the administrator of the site, and he wanted to remote into my machine since it had looked like my permissions had been set correctly (and had been for the previous month). I double checked to make the error still happened since I did not want to waste his time, and sure enough, it still was occurring. I gave him remote desktop permission, he logged in and everything just worked. No changes had been made, he did not change any of my login information – nothing was different except he was controlling the machine.
This happens to us all, and I guess it was just my turn. At least I can log in now and get to the server properly.
Questions, comments, concerns and criticisms always welcome,