Tuesday, September 28, 2010

“Non-Reproducible defect” – Non-occuring or “Unable to recreate?”…

Non-Reproducible defects, sometimes, are even more lethal than existing defects. If ignored, you can never predict when the non-reproducible defect would rear it's ugly face and kill the product. Trying to present a personal perspective of "top 5 myths" around non-repro defects.


Myth 1: That non-reproducible defects are harmless

Not really. When it's happened once, it's more likely that it can happen again. Non-occurance in a protected environment does not mean permanent non-occurance in production. Secondly, can the defect can be ignored since it cannot be re-produced? Definitely not. Test around areas of the defect to explore it further. You never know what you can unearth unless you dig further!!!

Myth 2: That the development team have fixed the non-reproducible defect

A personal favorite. I have heard many stories of dev fixing non-repro defects. How do you verify a bug-fix that's not reproducible in the first place? I don’t know. I have never figured it out. Maybe they know something that you don't. If you have good interpersonal relationships with the developers, you should be able to talk to them to understand the root cause to try and re-create the error conditions to reproduce the defect and confirm if it’s fixed.

Myth 3: Large number of non-reproducible defects? No, it doesn’t’ mean much

Maybe a large number of non-reproducible defects means the following
a) Test Conditions are varying due to test environment instability
b) Testers have not understood product design
c) Dev and testers don’t talk to each other
Whatever it is, it means chaos!!! And that's a ill-omen and bad-health for the product

Myth 4: That the non-reproducible defect is a scenario that's never happenned before

If it’s an application in production, (a maintenance application), maybe it’s happened before. Look around.
a) Talk to the support teams to check if it's happenned in the past.
b) Talk to the veteran project members to see if similar defects have been unearthed in the pasts.
c) Look into the bug database.
d) Check the support log files (if you have access to support calls).
e) Network with older project testers who you are in touch with (even though they have moved to other projects or companies).
f) Maybe it's happenned earlier in life and you can get some info from earlier people. Also talk to people who have tested the application earlier to see if it's happenned in the past.
Remember, History is a great teacher!!!

Myth 5: That the sole owner of a non-reproducible defect is the tester

Non-Repro defects are mentinoed as errors of the tester. I Disagree. It's more like a case of a person being punished for trying to reach objectives beyond boundaries. When a tester tries to invest time in trying to showcase a rarely occuring problem, we are actually punishing him by thrusting ownership on him. Metrics crazy companies have assigned metrics for each developer and tester, and I am pretty sure that this results in the tester being blamed if a defect’s non-reproducible.

My take --> I feel that this defect should be owned by the entire project team. No single person ownership for non-reproducible defects.

Fake Tester's Gyan

1) Dont' ignore them

Most of us tend to ignore the defects which cannot be reproduced again. It's akin to commiting suicide. Please ensure that you address all non-repro defects before going live. Ensure that the right people get to view them and discuss them accordingly, before deciding on next steps of these defects.

2) A non-repro defect session

Why is it non-reproducible? Have a session with the entire project team to brainstorm regularly on all non-reproducible defects in the project. Maybe we would understand patterns on why a defect is non-reproducible!!!.

3) Business Severity

And look at business severity, as always. If it's high priority, then please spend some more time looking into areas. Try defining test conditions. Look for cases outside the requirements. Maybe it’s the slow system, slow connection speed, memory leak, etc. that’s resulting in this behavior. Classify high priority non-reproducible defects into a bucket and spend 1 hr a week analyzing them. It's better spending time on bug research now instead of doing it after the system goes live.

That's all!!!

As always, happy testing!!!

Monday, September 13, 2010

Happy Programmer's day!!!

Hi Programmers,

Best wishes from the fake software tester for a wonderful and bug-free "Programmer's day" :) !!! Yes, for those who don't know what I am talking about, Sep 13 and Sep 12 (in a leap year) is celebrated as Programmer's day, at least in Russia!!! And I am not surprised.

The logic behind this is to celebrate the 256th day of the year as the Programmer's day. As you know, 256 was chosen since it can be represented with an 8-bit style. But, I have the following question behind celebrating the 256th day.

Don't you guys think that your counting should start from Day-0 and celebrate Day 256 (which'd fall on Sep 14 and Sep 13 on leap years) as a programmer's day? Your guess is as good as mine. Maybe we can log a defect against the above logic :) !!!

And What about a tester's day? Maybe it can be celebrated the following day, for the simple reason that testing follows development. Happy Tester's day too!!!

Friday, September 3, 2010

Look Closer…He's a Manager, not a mentor!!!

Today's world expects managers to play a mentoring role to all of their team members. But this expectation seems fundamentally flawed. It is actually very difficult for a manager to be an "effective" mentor to his team members. Why? Why? If you are really interested in my opinion, please read-on.

1) Difference in Priorities
A manager's priority would be the company's good health. A mentor's priority would be your good health. An example is -- your manager would never ever advise you to quit your job to reach your goal, your mentor would!!! Basic difference in Priorities is the 1st hurdle for a manager to be a mentor.

2) Interests Vs Loyalties & Following your Dreams
When your interests and corporate interests clash, a manager would advise you to do what's beneficial to the company. A mentor would nudge you towards what'd be beneficial to yourself.

For example, if you are a very good black box tester in a manual testing company, with an aspiration towards networks, a manager would show you a nice career path in the direction of black box testing, while your mentor would ask you to follow your dreams. A mentor would most probably say --- "Use this job for sustenance, do a course in networking and join Cisco"!!!

3) Favoritism towards top performers
Managers are bounded by loyalties towards old-timers, loyalists & top performers. The manager does not invest time in a weak performer. But Mentors don't let down a weak performer. You would want a mentor, who would not let you down, don't you?

4) Are you his Competitor?
When your mentor becomes your manager, the following question might creep into your mind --- "Is my career not progressing because he thinks I am his competition?” Somewhere down, your mentor, your manager, becomes your dreaded enemy and sadly, a rival!!!

5) And the Credit Crunch...
When your mentor becomes your manager, who do you think gets credit for a successful launch, and who do you think gets blamed for failures? Work becomes more difficult when this question takes root into your head. As we all know, a mentor would always take the blame for failure and credit you for success.

6) Confessing your faults...
It's very difficult to confess your weaknesses and faults to your manager. You would have the belief that it'd come back to haunt you during your "appraisal time". But, you would never have this fear confessing this to your mentor!!!

Those are some blockers that I could think of... as to why managers should not try their hand at mentoring... They are called Managers... and should strictly stick to Managing!!!

And no, I am not even hinting at asking you to get through life without a mentor... That borders on insanity!!! You always need a mentor to guide you in the right direction.... The results can potentially be hazardous when your manager becomes your mentor... or vice-versa!!! And below is my suggestion to solve this.

The Internet has shrunk the size of our world. That means it's possible for you to reach out to anyone you want who resides at another corner of the world. So, please reach out... scan the entire world to identify your mentor. If you are looking at your manager to do it, then...keep in mind, he's a Manager first...then a mentor!!!