Finding such subtle bugs is the most challenging work and it gives you the satisfaction of your work. Also, it should be rewarded by seniors. I will share my experience of one such subtle bug that was not only difficult to catch but was difficult to reproduce also.

I was testing one module from my search engine project. I do most of the activities of this project manually as it is a bit complex to automate. That module consists of traffic and revenue stats of different affiliates and advertisers. So testing such reports is always a difficult task.

When I tested this report it was showing the data accurately processed for some time but when tried to test again after some time it was showing misleading results. It was strange and confusing to see the results.

There was a Cron (Cron is an automated script that runs after specified time or condition) to process the log files and update the database. Such multiple crops are running on log files and DB to synchronize the total data.

There were two Crons running on one table with some time intervals.

There was a column in the table that was getting overwritten by other Cron making some data inconsistency. It took us a long time to figure out the problem due to the vast DB processes and different Crons.

My point is trying to find out the hidden bugs in the system that might occur for special conditions and causes a strong impact on the system. You can find such a bug with some tips and tricks.

So what are those Tips:

#1) Understand the whole application or module in depth before starting the testing.

#2) Prepare good Test Cases before start to testing. I mean give stress on the functional test cases which include the major risk of the application.

#3) Create sufficient Test Data before tests, this dataset includes the test case conditions and also the database records if you are going to test DB related application.

#4) Perform repeated tests with the different Test Environment.

#5) Try to find out the resulting pattern and then compare your results with those patterns.

#6) When you think that you have completed most of the test conditions and when you think you are tired somewhat then do some Monkey Testing.

#7) Use your previous Test Data pattern to analyze the current set of tests.

#8) Try some Standard Test Cases for which you found the bugs in some different application. Like if you are testing input text box try inserting some HTML tags as the inputs and see the output on display page.

#9) Last and the best trick is to try very hard to find the bug. As if you are testing only to break the application!