Tips for Finding and Filing Issues When QA Testing

As a functional software tester, I’ve been finding issues and logging them into different bug reporting systems for quite some time. Generally, we test functionality based on written test cases and, while logging a bug, know the basics about what information we should provide to help developers find the root cause.

I’m going to share some tips that have helped me in both finding issues and providing the right information when logging the issues. These are a few points that functional testers should keep in mind:

  • When testing the application, it’s always better to clear the cookies/cache of the browser unless it needs to be there while testing
  • When you are testing the front-end or UI of the application, keep the developer tools window open (generally done by pressing the F12 key) and while the page is loading, see if there are any warnings or errors there. Sometimes I would observe that even though the UI is working fine, there were some warnings on the console
  • Always provide some extra information when logging an issue because it may help the developer fix the bug faster. Also while testing the fix, it would allow you better access to which scenarios to regress
  • Tally your application logs at the web/app server. There could be some instances when your application will work as expected, but you will still see a warning or error message, which could potentially be a bug
  • Support multiple Internet Explorer versions. If you are expected to test your application functionality on different versions of IE, don’t use the “Compatibility Mode” of the browser because you might miss some issues. Instead, use the actual browser for testing
  • When you are testing the UI, try using keyboard shortcuts. These might uncover some issues that would otherwise be hidden
  • When you’re testing a fix for an issue, try to get the change-list number that the developer checked-in for the fix. Use that to look into the code change by that number and assess what changes have been done. You might find this useful to help you decide what test you need to run to get the bug properly regressed. You can also ask the developer to give you a pseudo-code, if possible
  • When you’re writing the bug description, put the test cases number that you would rerun while regressing the issue. This will give the developer a better understanding of the scenarios they need to test when fixing the issue, and decrease the possibility of having to reopen the issue
  • It’s good practice to sit with the developer and discuss the fix in terms of different use cases the code needs to support. This allows the developer to unit test the code while keeping the different use cases, which would result in fewer reopened issues
  • Sometimes the developer fixes the bug without thinking about the entire context of functionality, so it’s always better to discuss your ideas with the developer to ensure full clarity

Those are a few tips that I’ve discovered from my experience as a functional tester. They’ve made my job a lot easier and have helped developers not only find more bugs, but also fix the bugs faster. I hope they help!

Mohd Azeem

Mohd Azeem

Quality Assurance Lead

Mohd Azeem is a Quality Assurance Lead for 3Pillar Global. He has over 8 years of experience in the field of Quality Assurance with various domain knowledge of Services, Investment Banking, LMS, and ITIL. Prior to joining 3Pillar, he worked with Hewlett-Packard and 360Logica. He holds an MCA from HBTI Kanpur.

Leave a Reply

Related Posts

Interviews from Industry Summit 2017: the Product Conference On this special double episode of The Innovation Engine, the 3Pillar team interviews many of the speakers who took the stage at Industry Summit 2017. ...
Designing the Future & the Future of Work – The I... Martin Wezowski, Chief Designer and Futurist at SAP, shares his thoughts on designing the future and the future of work on this episode of The Innovat...
The 4 Characteristics of a Healthy Digital Product Team Several weeks ago, I found myself engaged in two separate, yet eerily similar, conversations with CEOs struggling to gain the confidence they needed t...
Recapping Fortune Brainstorm Tech – The Innovation Eng... On this episode of The Innovation Engine, David DeWolf and Jonathan Rivers join us to share an overview of all the news that was fit to print at this ...
4 Reasons Everyone is Wrong About Blockchain: Your Guide to ... You know a technology has officially jumped the shark when iced tea companies decide they want in on the action. In case you missed that one, Long Isl...