MIS-S-TAKE

OOOO…, as scripted in my previous post, I really had a long break but my learning process had enough(sometimes more than enough) to digest.

“Rough patches always teach you many lessons” -> I had many patches to scribble about… and I am here now with some of my mistakes (that will not be a nice idea!!!) but considering the fact that, it will help OTHERS.. I will unzip some of my mistakes in upcoming “MISS TAKE” posts..

Once, I was in a situation to set up some critical Testing trap, with all necessary matching criteria, I decided to do it myself because explaining the trap to someone and seeking their help will be a time consuming process.

I have started setting up the trap in a hurry(time is always a constrain) and as always, I had some time left after setting up all the things, so I shared the core of the trap with one of my colleague(fortunately) with intent of sharing my testing knowledge (and also to show my testing EGO.. ), --> But then came my downfall..

He figured out a vital misStake which would have easily spoiled my entire testing.

In the making, I had to execute a system command that will trigger things in backend and send back a message “Everything has been executed successfully”. I executed that system command and I got the cheers message “Everything has been executed successfully”… BUT in the backend the required thing doesn’t happen.. :(

Yes of course, Testers should not believe in any system (even though it is not the built to test).

I am really worried after that incident and the reason is simple that I would have re- checked/assured everything went well behind the screen as well.

Its really important to recheck and assure that we have done a nice job because it will definitely save time and extra effort.So I came to a conclusion that, I want to make sure everything I do for testing purpose should be double checked. But how to assure that you have checked + rechecked your test activities.

Old idea but evergreen .. Checklist ..
Don’t take it in a wrong way, I am not saying you to do checklist testing but to use a checklist just to make sure you test everything perfectly…:)

I have implemented the above in some of my daily activities and it really works.. there will be “n” number of ideas to fix any issue.. hopefully one of you can help me out with something new and innovative... :)

Some interesting Q’s on mistakes..
a)If you commit a mistake then it indicates that you are working (not Idle).

b)When others make mistakes, we say “they are incapable”, but when we make mistakes we say “we learn from mistakes” -> tweeted by Viru … I hope, he has learnt so much from his patches…. Just for fun … :)

Be united to be an Independent.

Happy Independence day.

Lets key down our mistakes to help ourselves and others,
Venkat
All izz well….
Catch me @kpvenkatesan84@gmail.com

Discover the pattern...

“There will be some non-reproducible bugs” – This was my initial belief until that “T” break.

10 minutes before that “T” break:
At that time, I was part of a testing team which was given the task to test an application, which was already tested by a team (second phase) and we had their test report. A bug was mentioned in a column named “Non-reproducible bugs” of that test report.

My first instinct on seeing that report was “This is not a reproducible bug so we can't reproduce this bug" and not to my surprise, the whole team(including our team lead had the same thought on non-reproducible bugs).

->“venkat, lets go down for T”(in Tamil). that was Mr.X (Identity under cover).

During T :
We shared so many things (starting from how we can kill our time(holidays) in gulf to our Indian cricket team) and when our topic squeezed into our work, I shared the above non-reproducible bug column, the next moment his face turned sick and he said “These testers are so incapable that they couldn’t reproduce a bug”.

With little fear-factor, I asked him if a bug can’t be simulated again, then what’s wrong in categorizing it as a non-reproducible bug?

He smiled at me and said “Each and every bug can be reproduced. Only due to some constrains(like time and considering the severity of that bug. It will be deferred/ put into that “Non-reproducible” column)”. Take it from me, every bug will definitely have one/more patterns. Simple/hard thing is “you have to find that pattern”.
He also said “Don’t believe in all those theories and shutter yourself at this initial stage of your career”.

I nodded my head as reply and we departed.[ he(42 yrs old) ran through the steps but I slowly headed upstairs].

After T break :
I have decided not to work on that non-reproducible bugs immediately, so I postponed that to post-lunch and during lunch time, I shared that thought to my fellow tester, he laughed at me and said “Don’t waste your time buddy” but post-lunch, I again stressed him “Mate, lets try that out”.
It took a lot from three of us (nearly 1hr and 20 minutes of questions, tricks and guess works, tackling traps..).

Actions performed: (we haven’t planned anything at that time, but now I can relate those things to below).
a) Gathered maximum information from that tester, who logged the bug(we asked him to sit with us) .
b) Analyzed test data (To find whether this bug sparks out only when we use some kind of test data).
c) Random usage of that particular functionality (with proper log).
d)Prepared various patterns(guess works- Functional/non -Functional).

Finally, The tester, who logged the defect helped us to discover the exact pattern to reproduce that bug ... :) and we all three had that victorious faces but the credit goes to Mr.X (hope, I can catch up with him again).

-> Reproducing a bug is as important as of finding a bug.
So if you have a non-reproducible bug column in your test report, please remove it and start discovering and once you have decided to discover the pattern, I am sure, you will meet that irregular bug at least once and after that it will be just a matter of uncovering it...

Have a break........ :)

Lets discover,
Venkat.
All izz well.
Catch me @ Kpvenkatesan84@gmail.com.