A very good and important point. Right? If you are a software
tester or a QA engineer then you must be thinking every minute to find a
bug in an application. And you should be!
I think finding a blocker bug like any system crash is often rewarding! No I don’t think like that. You should try to find out the bugs that are most difficult to find and those always misleads users.
Finding such a subtle bugs is most challenging work and it gives you 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 consist of traffic and revenue stats of different
affiliates and advertisers. So testing such a 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 a automated script that runs after
specified time or condition) to process the log files and update the
database. Such multiple crons 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 table that was getting
overwritten by other cron making some data inconsistency. It took us
long time to figure out the problem due to the vast DB processes and
different crons.
My point is try to find out the hidden bugs in the system
that might occur for special conditions and causes strong impact on the
system. You can find such a bugs 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 includes major risk of the application.
3) Create a sufficient test data
before tests, this data set include the test case conditions and also
the database records if you are going to test DB related application.
4) Perform repeated tests with different test environment.
5) Try to find out the result 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 analyse 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 try very hard to find the bug As if you are testing only to break the application!
Meantime you can comment out more tips here.
No comments:
Post a Comment