Bugs are always in software. No Application is bug-free. Testing reduces the probability of undiscovered defects. If Testers or automation scripts cannot find any defect, it does not mean the software is bug-free. Even multiple testing techniques can never guarantee that software is 100% bug-free. Testing can decrease the number of defects but not remove all defects.
Test for all combinations of inputs and preconditions is impossible except for trivial cases. Unless the application under test has a straightforward logical structure and limited input, it is impossible to test all possible data combinations and scenarios. Attempting exhaustive testing on complex applications is not an efficient use of time and budget. For example, If you have an email field that accepts alphabets, special characters, and numbers, it would have numerous combinations for testing, and testing all combinations is exhaustive testing. So, instead of exhaustive testing, we can use risk analysis, test techniques, and priorities to focus testing efforts.
Testing activities should be started as early as possible in SDLC. The testing team should be involved in the project from the beginning. An important point about early testing is that when defects are found earlier in the life cycle, they are much easier and cheaper to fix. For example, In Agile, we test the requirements before coding begins. Early testing is sometimes referred to as a shift left.
A small number of modules contain most of the defects discovered during pre-release testing or show the most operational failure. We can relate Defect Clustering with Pareto Principle. According to this Pareto Principle, approximately 80% of the problems are found in 20% of the modules. Thus, we prioritize testing on 20% of modules where we experience 80% of bugs. Defects are not evenly distributed; they cluster together. If so many defects are detected in one place, there is a possibility that more defects would be there.
Tests are no longer helpful at finding defects, just as pesticides are no longer effective at killing insects after a while. Test cases need to be regularly reviewed and revised. If the same tests are repeated on the same release, it will not find any defect and lose effectiveness. You need to update and regularly add test cases to detect new defects.
Testing is not the same for a different type of software. Banking and E-Commerce applications are tested differently than safety-critical software. You might use a different technique, methodologies approach, and testing types based on the application type.
It is impossible to run all possible tests and find all possible defects. Further, it is a fallacy to hope that just discovering and fixing a large number of defects will guarantee the success of a system. Finding and fixing defects does not benefit if the system build is unusable and does not meet the user's requirements. Even bug-free software may be worthless if incorrect requirements are incorporated or the software fails to meet the business needs.