5 minute read

Everyone reports bugs. Users, UX folks, product managers, developers, testers, and QA. But not everyone gets to decide which bugs are important enough to get fixed. This is the role of a PO/ Engineering Lead. 

Everyone who has ever used software would have also run into a ‘bug’ at some time or the other. 

A software bug is some kind of error or fault in a computer program or system that prevents it from working the way it should. It creates an unexpected or incorrect result. 

What, then, is an ‘invalid’ bug?

An ‘invalid bug’ is a bug reported by a tester or anyone that arises because of a difference in the understanding of the software program under test. It could also be due to a lack of understanding of the software program being tested. An invalid bug might also be reported if the ‘environment’ in which the software is being tested is different from the environment it was built for, or because of a changed requirement, a functionality that is yet to be implemented, etc. 

Commonly, bugs are marked as invalid due to insufficient troubleshooting/investigation by the tester before reporting the bug. 

Why are these reported bugs ‘invalid’? 

The top reasons why bugs reported by testers are marked ‘invalid’ include:

1. Improper understanding of requirements 

If a requirement has been understood improperly, the tester will look out for the misinterpreted requirement in the Application Under Test (AUT). When that requirement is not found, the tester reports it as a bug. This reported bug would eventually get rejected as an invalid bug. 

Consider this real-world analogy. You go to a restaurant and order a cup of tea. The tea is served. You sip the tea and complain that the restaurant has forgotten to add sugar. Had you known that the ‘requirement’ was for the sugar to be served separately for the restaurant’s patrons to add sugar as per their individual tastes, you would not have ‘reported’ this. 

2. Changed requirements

Often, requirements change while the project is underway. If these changed requirements are not communicated to the testers, these will be reported as bugs and later rejected as invalid. 

In our real-world analogy, you go to a restaurant with a friend and order two cups of tea. However, when the waiter arrives, they come bearing two cups of coffee. You are upset with the waiter. You are not aware that while you were on the phone, your friend had changed the order from tea to coffee. 

3. Changed implementation 

At the start of the project, it was decided that requirement ‘A’ would be implemented in an ‘X’ way. However, during actual development, it is found that requirement ‘A’ can only be implemented in the way ‘Y.’ If this change is not communicated to the testing team, the changed implementation will be reported as a bug. 

Consider this real-world analogy. You organize a party for your friends. You decide the menu with the caterer and place the order. However, due to the non-availability of an essential ingredient, the caterer replaces menu item ‘X’ with the equivalent item ‘Y.’ When the food arrives, you are surprised by the changed ‘implementation.’ 

4. Poorly specified requirements 

Imprecise and unclear requirements give rise to multiple interpretations. Differences in interpretation of requirements lead to differences in interpretation of test results, leading to this being reported as a bug. 

Let’s say your architectural firm is told to design a building. This requirement could be interpreted to mean a house, an office building, a mall, a school, etc. Requirements need to be specified precisely to prevent the possibility of multiple interpretations. 

5. Variation in the test environment 

An application/software product can only function as intended in a specific environment. This specific environment is a combination of several hardware/software elements. When any element in the environment is missing, the software will malfunction. This malfunction gets reported as a bug. If the application is tested in the wrong environment, it results in an invalid bug. The testing team should ascertain the completeness/correctness of the environment before commencing the testing.

Your friend baked you a cake. You find it delicious. You get the recipe and bake the cake exactly as per the recipe. It does not taste as good. Later, you discover that your friend had baked the cake in an electric convection oven. You, however, used a microwave oven. The right ‘environment’ matters. 

Reporting bugs: Good practices 

If a bug is reported correctly, it increases the chances of the bug being fixed. Writing a good bug report is a skill. 

Adherence to the following best practices can enhance the effectiveness of a bug report: 

  • Be clear and concise in reporting the bug. A lack of clarity in the bug report leads to misinterpretation and slows down the development process. 
  • Check for duplicate bugs. Duplicate bugs burden the development/testing cycle. Tools like Bugasura Reporter can help in automated checking for duplicate bugs.
  • The report should help the developer visualize the problem. The bug report should provide the developer with all the information to help understand the reported defect. 
  • The bug report should lay out, in detail, the conditions under which the test was performed and the defect(s) observed. The developer should be able to reproduce the bug independently. 
  • It is a good practice to list each bug separately. It enables each bug to be addressed individually. A bug report is closed after all the bugs have been addressed.
  • Using the right tone in the bug report is essential. Do not use an accusatory or a commanding tone. Software development is a collaborative process. Use a tone (suggestive) that elicits cooperation and collaboration. A simple thumb rule – do not use a tone that you would not like being used to address you. 
  • A bug report is part of the project’s records. Project records are preserved as archives for future reference. Make the report comprehensive and yet easily comprehensible. A future reader of the bug report should be able to extract and understand all the information contained in the report. 

Balanced Thoughts 

The hallmark of an effective bug report? 
  • The report is drafted with the understanding that the ‘quality’ of the bugs reported counts far more than the number of bugs reported. 
And the objective of the bug report? 
  • To contribute to improving the quality of the software product being developed.
So, what can you do to avoid reporting invalid bugs? 
  • Insufficient troubleshooting by the person reporting the bug is the chief reason bugs get marked ‘invalid’. Before reporting a bug, it is important to troubleshoot to identify the reason for the failure(s) in the AUT. 

Check for the following common pitfalls. You will never again report invalid bugs. 

  1. Ensure that any configuration file you might be using for testing the application is updated as per the AUT’s requirements. Failure to do this will cause the AUT to malfunction. If reported, this will be marked as an invalid bug. 
  2. Check for the completeness of your database. Often, a missing table in the database is the reason for a malfunctioning AUT! 
  3. Verify the compatibility of software versions. 
  4. Check the test machine to ensure that all the software components have been installed correctly and that the registry entries are valid. 
  5. Check for the correctness of the application’s hardware and software prerequisites. 6. Before commencing testing, ensure that the latest version files are uploaded to your test environment.
  6. Check out Bugasura here