You didn’t find bugs.  If that continues, you could be out of a job.

Okay, it’s not that bad. But it is sometimes worrying when your job is to find something that someone else did wrong.  While part of you may feel good that an application, module, or patch is bug-free – part of you feels like you haven’t done your job if you didn’t find at least one issue.  And, that worry isn’t without foundation.  Some managers feel that way as well.

But it may not be the case.

It’s entirely possible that the type of tests you’re running could play a part as well.  If you’re doing performance testing, or just a smoke test, there’s a chance you won’t find any bugs.  That certainly doesn’t mean you didn’t do your job.

Another possibility is that a number of bugs were found and fixed before ever being coded.  That’s right, when you find something incorrect in the requirements, point it out, and remedy it…you found a bug. You just found it before it was coded since not all bugs are found and fixed after coding. Give yourself some credit for that, because you saved everyone time and money by finding issues before they were written into the application.  And certainly, keep track of such things if you have a manager that questions the value of QA.

But, there is also chance that you do need to brush up on some skills. Are you testing a new application that you’re less familiar with?  If there’s a database involved, did you create tests for data integrity, size, type, etc?  Are you testing data transmission without understanding protocols?  No matter how long you’ve been testing, everyone can benefit from refreshing and updating skills.  Software changes rapidly, as do development processes, types, and styles. If you’re consistently not finding bugs, you might want to brush up on different methods of testing.

Not finding a bug can be helpful as well.  Consider the situation that certain parts of the application under test always break when modified.  While other parts never break when modified.  This kind of information can be extremely useful to developers.  Also, pointing out usability issues are an integral part of your job. While they may not be “bugs” per se, they are issues and within your domain.  Finding and pointing those out (prior to or after coding) means you’re doing your job.

Being a good tester doesn’t just mean “breaking” software.  It also means preventing bugs from being coded, pointing out consistent problem areas within an application, and helping to make sure the customer will enjoy their user experience.