Last week, i had reviewed the bug reports submitted by my team & found that some of them are not reproducible. I am curious about where things went wrong & checked with the team.

Some of the Responses:

• Look Venkat, this bug is not-producible always. So we have captured the log.

• It does occur if we re-start the application

• It takes good amount of time for the investigation

As a Tester, i have come across of situations where some bugs won’t reproducible again and i infer that many of the testers might have gone through the same episode atleast once.

But then, Non-Reproducible Bugs are errors of the testers even though we may not agree. More over this is true for Technical Support & Testing functions.

It’s tough for the Developers to work with such bugs and testers used to get lot of objections over such bugs. If the count is more, then it might spoil the relationships between testers and developers.

An Insight

I infer from my experiences that systems doesn’t have the powers of human brain. It’s tough to repeat the same mistake again from people since they are conscious. Systems doesn’t have that much capability interms of thinking and they do perform the sequence in which they have coded for.

How do deal with Non Producible Issues

Testers need to improve their skills inorder to reproduce such issues. The following might be a help.

• Try to capture the story around the issue and not just steps.

• Capture the complete Test Enviroment

• Capture all the available Test Execution Results. This includes your test data, screen shots, applications logs, system logs, server logs

• Need more patience (they won’t occur easily)

• Need more observation skills on the application behavior under test.

• Narrate the story around the issue to the stake holders and to corner the issue.

• Resources & Time Contraints might be an issue (More true for Tech Support). Bargain for the same

Conclusion

They are bound to take lot of time & resources in the process. It’s suggested to reproduce each & every issue. We must explore more for the critical issues & re-produce them asap. In the process, we learn more too.

Happy Testing.

Bugs are part of day to day life of all software development teams. Many upcoming testers use Microsoft tools like MS Word, Excel, Notepad in the process of exploring their testing skills to validate software applications. Here, i would like to share very old article on Chasing Bugs In the Electronic Village by James Gleick. This article was published in 1992 & James shares his views on chasing issues in WinWord.

Though many things have been changed over the time, there are still some patterns exists on the bugs in applications. Though, Microsoft Tools are most widely used software across the globe, it still comes with lot many issues with them.

The following seems to major issues

• Behavioral Patterns of the end users in using the applications
• Less focus on the non functional needs like Usability, Accessibility, Performance etc
• Scalability of the applications to handle large volumes of users and data
• Simulation of all possible application environment for end users
• Change is the only constant thing and the software applications ability to support these rapid changes in terms of user needs and technology.

Software Testing & Quality is overlooked most of the time and it’s quite common to see buggy software in the market. Some of the projects ship software without even having dedicated testers & in some other projects due to budget constraints there are less resources. I was going through Joel on Software site and come across this Joel on Software – Top Five (Wrong) Reasons You Don’t Have Testers

As per Joel Perspective the reasons are

1. Bugs come from lazy programmers.
2. My software is on the web. I can fix bugs in a second.
3. My customers will test the software for me.
4. Anybody qualified to be a good tester doesn’t want to work as a tester.
5. I can’t afford testers!

Won’t they look similar in your context.