1. Testing Shows the presence of defects, not their absence
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.
2. Exhaustive testing is impossible
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.
3. Early Testing saves time and money
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.
4. Defect Cluster together
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.
5. Beware of the Pesticide Paradox
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.
6. Testing is context-dependent
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.
7. Absence of errors is a fallacy
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.
.png)
.png)