New bug Interpretation

I have been doing software testing for almost two years, but there is always a problem that is always disturbing me. I have been wondering what kind of problem is called a bug, should we submit a defect ticket when encountering this type of defect? As a tester, what kind of defect should we propose as a good tester. As a tester, do we only need to mention any defects? Is bug definitions the same for every company? In this company, is it true that such problems are identified as bugs in another company?

With these questions, let me express my opinion on the bug. I think any bug is based on the cost. Let's think about it. If the product is not tested, it will be put into the market. If the cost for modifying problems after the market is less than the cost for hiring testers, I think there will be no testers, but the opposite is true, however, if our products are put into use without testing, the cost of modification is much higher than the cost of hiring testers, that's why we have a very good report (a bit exaggerated) on the "money" scene in the testing industry ).... To the above. Determining whether a bug is the benefit of fixing this bug, which is greater than the benefit of not modifying this bug. The following describes how the master interprets the bug. Their explanation of the bug is as follows:

The final purpose of the production software is to meet the customer's needs. We take the customer's needs as the criteria for judging the software quality. The specific meaning of Software defects includes the following factors:

☆Functions and performance of the software that does not meet the customer's needs;
☆The software is beyond the scope of the customer's needs;
☆Software errors that cannot be tolerated by customers;
☆The use of the software does not conform to the customer's habits and work environment.

Now let's explain each of the above points.
1. functionality and performance of the software that does not meet the customer's needs;
If everything you make does not meet the customer's needs, then what software do you do? Who will pay for it? So this is in line with the related charges.

2. The software is out of the scope of the customer's requirements.
If you do not pay for anything beyond the scope of your customer's needs, where are your development, testing, and maintenance costs.

3. software errors that cannot be tolerated by the customer's needs and the use of the software fails to meet the customer's habits and work environment.
These are problems that affect the customer's mood and efficiency, or affect the customer's profitability. Of course, we have to do a good job. How can we make other people willing to pay the money.

The above may be a bit messy, but I still want to answer the question raised. The tester does not only need to discover the problem. If we perform a very abnormal test, we can indeed find many problems, however, it is possible that such problems will not occur at all, or they will never happen in the software life cycle. Is there any need for us to raise such problems, therefore, when conducting an exception test, the tester must test it with the mentality of discovering defects, but it should not be a non-disruptive test. Reliability tests are now popular, but do companies need to perform reliability tests? Do companies have the same requirements for reliability. Of course, the answer is no. What kind of Chengdu should be like service availability and maintainability.

To sum up a few words. The bug in your company is not necessarily known as a bug in other companies. Today, the bug may not be a bug yesterday. The purpose of the tester is to discover the bug, but not all the defects are worth modifying.
The last sentence: What kind of price determines what kind of product, and what kind of product determines the criteria for determining bugs.