Long time! I know, but I'd been quite busy with loads of things.
This time, I don't have much to share, but a bit of insight into my own work area - software testing, that I thought I can share with my colleagues. One of the most serious problems in the software testing any day, has been about non-reproducible or un-repeatable bugs. I bet there has never ever walked/lived/slept (all the same!) a software tester in this world, who hasn't experienced it. It shows up its ugly face in all software shops and occasionally at customer places too. It has been a phenomenon that is nothing short of a night-mare for most test engineers out there. Its effect are so devastating that most people on the job gets perturbed when confronted with the situation (and a few of them, even upon hearing about such situation elsewhere in their vicinity!), and then triggers off a chain reaction of all 'dirtier' things - bad feelings, less morale being quite commonly observed among these. This issue almost always occurs at the most inappropriate situations, including the day before the grand release of your software, leaving you wondering whatever you could do to save your face (if you're a manager, your grief is doubled)! How much ever you talk about this darkest side in a software tester's life, it isn't more. Every piece of what I described about it has maintained status quo since I started working a software test engineer 11 years ago and the scenario hasn't changed a bit today, if not worse.
Today, I read an article about the precise problem we were talking about so far. The author tries to give a newer, fresh perspective into this. It's a ray of hope for all the unfortunate testers, who didn't have an idea where to start looking for a solution. I feel strongly for it, and think must be attempted by all to root out this problem. While reading it, two statements of caution however. Don't be under the impression that you can remove the problem for ever from the face of the earth. Let's accept the fact, it's going to remain a problem, till software exists. We can only reduce its impact, but that in itself is worth all the effort. Secondly, this exercise is definitely not for the weak-hearted. Without sweating it out, you aren't going to solve it; that's for sure.
With all this introduction in mind, go ahead & read the article. Following are some points I quickly extracted from the article, and that I felt were critical.
• 'Unrepeatable' bug is a myth!
• 'Can do' attitude is essential to crack those especially nasty ones.
• Collaboration is important, especially between testers and developers.
• Look at the big picture.
• Keep notes of all your work.
• Watch for patterns among the different sightings of the bug.
• Hunches are often right. Follow them.
• Develop a catalog of failures and their causes as you go.
• Be humble, courteous, and respectful of others’ decisions.
• Don't believe what you see always, for the GUI sometimes creates a wrong impression about how it actually works.
• GUI may not be the best place to repeat all bugs.
• Keep yourself updated on 'state of the art' in architecture, programming & testing techniques.
• Automation is the way to go! Repeat bugs with less pain.
PS: CNR means 'Cannot Reproduce'
This time, I don't have much to share, but a bit of insight into my own work area - software testing, that I thought I can share with my colleagues. One of the most serious problems in the software testing any day, has been about non-reproducible or un-repeatable bugs. I bet there has never ever walked/lived/slept (all the same!) a software tester in this world, who hasn't experienced it. It shows up its ugly face in all software shops and occasionally at customer places too. It has been a phenomenon that is nothing short of a night-mare for most test engineers out there. Its effect are so devastating that most people on the job gets perturbed when confronted with the situation (and a few of them, even upon hearing about such situation elsewhere in their vicinity!), and then triggers off a chain reaction of all 'dirtier' things - bad feelings, less morale being quite commonly observed among these. This issue almost always occurs at the most inappropriate situations, including the day before the grand release of your software, leaving you wondering whatever you could do to save your face (if you're a manager, your grief is doubled)! How much ever you talk about this darkest side in a software tester's life, it isn't more. Every piece of what I described about it has maintained status quo since I started working a software test engineer 11 years ago and the scenario hasn't changed a bit today, if not worse.
Today, I read an article about the precise problem we were talking about so far. The author tries to give a newer, fresh perspective into this. It's a ray of hope for all the unfortunate testers, who didn't have an idea where to start looking for a solution. I feel strongly for it, and think must be attempted by all to root out this problem. While reading it, two statements of caution however. Don't be under the impression that you can remove the problem for ever from the face of the earth. Let's accept the fact, it's going to remain a problem, till software exists. We can only reduce its impact, but that in itself is worth all the effort. Secondly, this exercise is definitely not for the weak-hearted. Without sweating it out, you aren't going to solve it; that's for sure.
With all this introduction in mind, go ahead & read the article. Following are some points I quickly extracted from the article, and that I felt were critical.
• 'Unrepeatable' bug is a myth!
• 'Can do' attitude is essential to crack those especially nasty ones.
• Collaboration is important, especially between testers and developers.
• Look at the big picture.
• Keep notes of all your work.
• Watch for patterns among the different sightings of the bug.
• Hunches are often right. Follow them.
• Develop a catalog of failures and their causes as you go.
• Be humble, courteous, and respectful of others’ decisions.
• Don't believe what you see always, for the GUI sometimes creates a wrong impression about how it actually works.
• GUI may not be the best place to repeat all bugs.
• Keep yourself updated on 'state of the art' in architecture, programming & testing techniques.
• Automation is the way to go! Repeat bugs with less pain.
PS: CNR means 'Cannot Reproduce'
