I had to check a fix provided by a programmer to solve an issue.
I had to replace two files- One an .exe and the other .ini file.
Once I replaced the files, changed the contents of the files to suit my test and went through the steps to reproduce the issue, the issue was still reproducible.
So, I sent an email to the programmer that the issue is not resolved and the fix does not solve the issue. He wanted to have a look at my machine and try the scenario once.
Before handing over the control to the programmer, I copied the two files which were part of the test. This way I can compare the files after the programmer has completed his test.
The programmer was in Germany and was accessing the machine. I could not see what actions he was carrying out on the machine.
After ten minutes, I got a reply to that email that the issue is solved. Please re-test to confirm.
I was surprised and then along with my manager wanted to carry out the test. Before conducting the test, I wanted to compare the current file(after programmer conducted the test) and the file used by me to conduct the initial test.
And surprisingly, the contents were slightly different.
The initial file had 'Timer: 5:00:00 PM' and the new file had 'Time: 5:00:00 PM'.
Also, the programmer asked me to include an additional step so that the issue is resolved.
The additional step was to exit the service and run the .exe so that it may re-read the contents of the modified .ini file. I had not run the .exe after modifying the .ini file.
I replied back to him that the contents were changed and also the additional step was missed. These were the two reasons why I was able to reproduce the issue and he wasn't.
Learnings:
1. It is always safe to have a backup of files before and after conducting the test. Again it depends on what value this step adds to the overall mission. In my case, If I had not compared with the original file, there was very little chance that this issue would have been fixed before the customer found it.
2. Programmers have a natural tendency to fix issues on the fly. It is by nature that they fix issues and they do not consider it important to inform the tester about the changes. In my case, it turned out to be 100% true. The programmer never informed me about the change of text to 'Time' from 'Timer'.
3. I must have paid a bit more attention and come to the conclusion that the .exe must have been run to re-read from the .ini file. This taught me to relate the interaction between files & application to the tests I conduct using those files.
Simple things like having a backup of important files helped me find an important issue before it knocked the customer's door :)
9 comments:
:)
Thanks a lot Pradeep :)
A :) from you means a lot :)
Good set of learnings :-)
It could be a resource for other testers too who want to learn.
-Manoj
Thanks Manoj :)
The learnings were specific to my context and may vary depending on context.
Ajay san, thank you very much for sharing ..
Thanks Sachin :)
Very good learning. Programmers cannot stop themselves from fixing any issue they find dynamically without going through the formal process. A few years ago, I remember seeing someone doing bug fixes directly in the production (good that the programmer in your case just did the changes on the test machine) and trying to sync it in the dev/test versions later on (provided he remembered what he did to the production app).
This will continue to happen.
Thanks Ashwin for sharing your experience.
As it might happen anytime and anywhere, it's the duty of every tester to make sure that such things don't happen.
Alert Testers can prevent such mishaps :)
You did well, when you work with software and programming it is correct to have a copy of the original work in case errors arise in the process.
________________________
I work in factored ia
Post a Comment