To be a tester, be a developer (just for a bit)

Sometimes to know how green the grass is on your side just walk across the fence.

Lately at work I have been taking up the role of writing code which would actually ship. In other words I am not testing anyones code (except mine). And testing your own code is waaaaay too difficult than I thought it would be. But more on that in another post, some other day.

Here is a story. I checked in the first version of my program and awaited feedback. After waiting a day or so, and checking in another version, I walked up to the tester to check what was up (read: I tested my own code and found some bugs, did you find any more?). It seems she had apparently not looked into much of it. Not a problem.

Few more days pass by and no feedback yet. By then I had started doing what I love doing. Testing my own code and checking in newer versions. The good part of all this was after a few days I had really some robust code which I felt really confident about.

Yet, nothing beats another pair or eyes looking over your work. So by now I started pestering this tester to check my work. Finally I got comments from her which did put me in a state of partial shock. "Please change the way you have spelt CLick to Click." I had serious doubts in my mind. Is this a genuine comment after doing some solid testing or is this a "lets show I am on the job and keep him quiet for a while" kinda testing. Anyways, time went by and I didnt really hear from her. I got busy with some other modules and few days before shipping my favorite tester walks into my room and says she found a problem with my code. Now she did not pin-point the flaw but the code basically built a filter and and then did some analysis on the data which passed through this filter. As per the tester, there was certain data which should pass through the filtering mechanism but it apparently did not pass through mine. I wont get into the details right now, but it was difficult if not impossible to determine what that data was. All we knew is I had say 100 entries and she felt it should have been 101. All this few days before shipping.

Now changing my filter might potentially break the code somewhere else. Complete dilemma! And few seconds of anger for catching a bug so late in the cycle. Countless hours were spent stepping through my code. But somehow I couldnt figure out where I was going wrong.

Finally I walked up to the tester and asked her how she had come up with her numbers. It seems she had built a quick app which would do something similiar to what I was trying to achieve and had cross checked the results. Brilliant! May I have a look at that piece of code please? So I sat with her for a few hours and stepped through the code line by line. Finally we caught a bug in her code. Was I pissed off? No! I was relieved that my code worked fine.

What did I realize from this experience?

• A lot of heart beats are skipped when a bug is found very late in the dev cycle.
• At this stage when the dev. says "I refuse to change my code", he is pretty much justified. Of course this depends on the impact fixing this bug might cause across the application.
• As a tester if I do a bad job, it could thow others into a lot of trouble. A false negative is worst than a positive.
• More things which I will talk about later as the bell tolls.

But yes, being a developer for a wee bit has raised my bar of respect for developers. Specially those who do a good job.

And those who are wondering if I killed that tester, no I didnt. Everyone makes mistakes. Had she applied herself right from the start I would not have been grumpy. Unfortunately I did not see her do that. Every week I have to write a project update to my director. Also, everyone sends in a powerpoint slide to him listing what work they have completed in the week which passed by. My last bulleted point read something like "Did some testing. Found a bug in the code which tests my code." My director is a clever man. He understands the rest. :-D