If you are working as a tester, you know how important it is to find bugs in the software. Not to increase the bug count or amuse yourself, it’s essentially required to enhance the quality and build up confidence in your system so it can be sold better.
How many times have you been skeptical whether there will be any more bugs or have you struggled to find bugs sooner rather than later? Were you ever baffled where to look for to uncover bugs? When can you be sure that you have scrutinized all possible habitats of these creatures?
There are a few things which can be of immense help to testers when it comes to unveiling bugs.
Firstly, understanding the Requirement/Functional Specifications clearly and transforming them to Test Scripts will lead you to majority of the bugs. I need not say anything more about this.
Second very important area is understanding customer/business requirements. Software has to be functionally working as well as useful to the customer/business. There might be more than one ways to do a particular thing and your software should do it the way acceptable to the customer. Work your test scripts to explore this and you might find a bug or two. You might end up raising a few improvements as well, who knows!
Thirdly, Defect Taxonomies can prove to be very helpful in pointing you to the right direction. Defect Taxonomy is a method of gathering indications of problem areas. They are result of methodological analysis of probable vulnerabilities of the system and can give great test ideas to a tester. Each taxonomy category can result in multiple test ideas and there is no end to it.
You can create your own taxonomy specific to your application. For making it more intuitive and adding fun component to work, try using MindMaps and create test cases for each category. (who says writing test cases has to be documenting pages and pages of test scripts!!). There are heaps of these available on internet for free. Cam Karner’s work , http://www.kaner.com/pdfs/BugTaxonomies.pdf, gives a good insight into Defect Taxonomy.
Playing with test-data/platform/browsers/operating systems (if applicable) is a fail-proof way to discover some important bugs. Some issues occur only with a special set of data. You can apply test techniques like BVA and Equivalence partitioning to season the inputs/test data. Test your application on different browsers and mobile app on different operating systems.
People’s experience on same/similar projects is the next significant thing. It matters specially if you are new to a particular technology/platform. For instance, if you are testing a mobile application for the first time, getting inputs from someone who has previously worked on it may prove to be fruitful. People who have tested the functionality you are testing can point you to bug-prone areas.
Forums can play a crucial role in the way you approach things. Consider yourself in middle of circle, there are always people who have faced the issues you are facing today and some who haven’t yet. Read where others have found bugs, their issues. You will surely find something which didn’t cross your mind. It’s always better to communicate, share and learn mutually rather than working in silos.
Applying Pareto’s 80-20 Rule might help sometimes as well. Simply said, 80% of bugs reside in 20% of your application. You just need to figure out that 20% and exercise it as much as you can, in every possible way.
Last , but not the least do some Exploratory Testing. When your mind and actions are not governed by scripted defined tests, you can break rules , explore unknown areas and expect the unexpected! One needs to be a little cautious while doing this as it can go out of whack easily.
Whatever you do, it should be done with an intent of assuring the quality of system, not just to raise bugs.