{"id":1952,"date":"2022-03-04T10:08:36","date_gmt":"2022-03-04T04:38:36","guid":{"rendered":"https:\/\/bugasura.io\/blog\/?p=1952"},"modified":"2022-05-25T17:48:57","modified_gmt":"2022-05-25T12:18:57","slug":"whats-the-1-reason-why-people-report-invalid-bugs","status":"publish","type":"post","link":"https:\/\/bugasura.io\/blog\/whats-the-1-reason-why-people-report-invalid-bugs\/","title":{"rendered":"What’s the #1 reason why people report invalid bugs?"},"content":{"rendered":"<\/span> 5<\/span> minute read<\/span><\/span>\n
\"\"<\/figure>\n\n\n\n

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. <\/p>\n\n\n\n

Everyone who has ever used software would have also run into a \u2018bug\u2019 at some time or the other. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

What, then, is an \u2018invalid\u2019 bug?<\/h2>\n\n\n\n

An \u2018invalid bug\u2019 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 \u2018environment\u2019 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. <\/p>\n\n\n\n

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

Why are these reported bugs \u2018invalid\u2019? <\/strong><\/h3>\n\n\n\n

The top reasons why bugs reported by testers are marked \u2018invalid\u2019 include:<\/p>\n\n\n\n

1. Improper understanding of requirements <\/strong><\/h3>\n\n\n\n

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. <\/p>\n\n\n\n

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 \u2018requirement\u2019 was for the sugar to be served separately for the restaurant\u2019s patrons to add sugar as per their individual tastes, you would not have \u2018reported\u2019 this. <\/p>\n\n\n\n

2. Changed requirements<\/strong><\/h3>\n\n\n\n

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. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

3. Changed implementation <\/strong><\/h3>\n\n\n\n

At the start of the project, it was decided that requirement \u2018A\u2019 would be implemented in an \u2018X\u2019 way. However, during actual development, it is found that requirement \u2018A\u2019 can only be implemented in the way \u2018Y.\u2019 If this change is not communicated to the testing team, the changed implementation will be reported as a bug. <\/p>\n\n\n\n

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 \u2018X\u2019 with the equivalent item \u2018Y.\u2019 When the food arrives, you are surprised by the changed \u2018implementation.\u2019 <\/p>\n\n\n\n

4. Poorly specified requirements <\/strong><\/h3>\n\n\n\n

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. <\/p>\n\n\n\n

Let\u2019s 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. <\/p>\n\n\n\n

5. Variation in the test environment <\/strong><\/h3>\n\n\n\n

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.<\/p>\n\n\n\n

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 \u2018environment\u2019 matters. <\/p>\n\n\n\n

Reporting bugs: Good practices <\/strong><\/h3>\n\n\n\n

If a bug is reported correctly, it increases the chances of the bug being fixed. Writing a good bug report is a skill. <\/p>\n\n\n\n

Adherence to the following best practices can enhance the effectiveness of a bug report: <\/p>\n\n\n\n