My most embarrassing testing mistakes. (Part 2)

Premature Celebrations:

This is about a new product with six programmers and only tester (yours truly).

Something about the application:
This application had a login screen and as usual, unless one logged in with correct credentials, one could not use the application features.

I always have the habit of enabling the option 'Auto-hide the taskbar'. So even if a program is running, I would not know if its minimized unless I moved my mouse pointer near the bottom of the screen.

Now here is a classic example of me making a stupid mistake.

I launched the application by running the shortcut on the desktop.
I logged in with correct credentials and as my friend came to talk to me, I minimized all the programs including the application under test by pressing CTRL - D.

After talking to my friend, I saw the desktop.
Oh I forgot to test the particular scenario I had planned to test before my friend came to me.
Good that I remembered.

Let me launch the application. The moment I double clicked on the shortcut, I found something interesting.

The login window was on the foreground and on the background I had the application feature running.

For few seconds, I was a bit shocked with just one thought running in my mind.

"Have I cracked the login feature of this application. Have I bypassed the login screen? Have I found a way to access the application without entering any login credentials."

Cool! I had found a very critical bug.

When I moved the login screen aside and brought the focus to the application feature, I'm able to access the application without logging in.

As usual when I find a good bug, I called up my programmer and showed him this strange behavior.

He was confident that its impossible to see such a behavior.
Unfortunately for me, the programmer's manager was also around.

And why unfortunate? You'll soon know.

My application even if minimized would be restored to the full screen even if any other application is launched.

So what was a critical bug according to me turned out to be not at all critical.

The issue with the strange behavior had nothing to do with the login feature being broken.

It was just that when I double clicked on the shortcut, another instance had launched.

Again I had to face the sarcastic smile and remarks of the programmer.
I was so embarrassed that I felt like hiding somewhere far from these people.

A typical example of premature celebrations and lack of critical thinking on my part.

Lessons learnt:
> Generate new ideas to prove your bug as 'Not a bug'. The bugs which are not actual bugs would be filtered out.
> Learn to investigate any issue before terming it as an issue.
> Try to reproduce the issue and know its consistency before you talk to programmer.
Sometimes, its good to show any issue to your co tester in your team and have it criticized instead of making a fool of yourself in front of the programming team.
> Try to avoid disturbances if you are on a critical mission.
> Learn to focus and defocus and focus back immediately.

Learn to avoid raising false alarms like the boy in this story :
http://en.wikipedia.org/wiki/The_Boy_Who_Cried_Wolf

Leia Mais…

My most embarrassing testing mistakes. (Part 1)

Testing on the wrong build.

Every build was uploaded on the server on a particular day of the week. The release team would send an email once the build was uploaded on their side. It would take 4 to 5 hours for the build to be synched in to the local server. The testing team would check the date on the local server and copy the build from the local server and start their testing.

I was the one responsible to copy the build from the local server and start testing the build. After receiving the email from the release team, I waited for 4 hours and just copied the build folder.

I copied the folder, installed the build and started testing the last build.

I even logged a bug that the application about screen displayed the previous build version. So, the bug read ' about screen reads x.x.5 instead of x.x.6.

Continuing with my testing, I reopened two issues which were assigned to me as fixed. When the third bug fix also failed, I got suspicious and checked the build folder on the local server. It read the latest date and I thought the issues were not fixed on this build.

The programming team was also surprised and then checked the installed folders and found one of the .dll to be the old one.

The build folder was modified a week ago and the latest build had not yet been synched in when I copied the build. I did not care enough to check the folder modified date.

Wow!!! I was testing on the wrong build for the past 6 hours.

I had to uninstall the application, cut a sorry face in front of my manager and the programming team.

An experience I would never forget. Such mistakes often occur due to carelessness, casual outlook to testing and sometimes due to over confidence like in my case.

Lessons
From then on, I always check the build folder carefully and verify the one bug that clearly differentiates the two builds. I also have cultivated the practice of taking the screenshots of the folder contents of the current build and comparing it to the previous build screenshot and then start my testing once these checkpoints are cleared successfully.

Update:
You can ask me - What makes me enjoy such moments?

I enjoy my testing with the belief that such mistakes would not be repeated.
A waste of time/resource/cost to the company and to myself.

I'm happy that the mistake was not an expensive mistake.

Testers!!!
Beware of testing on the wrong build :)

Leia Mais…