Testing can show the defects are present, but cannot prove that there are no defects
As we find more defects, the probability of undiscovered defects remaining in a system reduces ( decreasing nature).
However Testing cannot prove that there are no defects present
Exhaustive testing is impossible
We have learned that we cannot test everything (i.e. all combinations of inputs and per-conditions).
That is we must prioritize our testing effort using a Risk Based Approach.
Test designing techniques can be helpful to prioritize the tests
Early testing
In the software development life cycle testing activities should start as early as possible
Testing activities should be focused on defined objectives – outlined in the Test Strategy
Defect clustering
A small number of modules contains most of the defects discovered during pre-release testing or shows the most operational failures.
Defects are not evenly distributed in a system, they are ‘clustered’
In other words, most defects found during testing are usually confined to a small number of modules ( 80% of uncovered errors focused in 20% modules of the whole application) “Pareto law”
Pesticide paradox
Testing identifies bugs, and programmers respond to fix them. as bugs are eliminated by the programmers, the software improves
If the same kinds of tests are repeated again and again, eventually the same set of test cases will no longer be able to find any new bugs.
Therefore we must learn, create and use new tests based on new techniques to catch new bugs ( i.e. It is not a matter of repetition. It is a matter of learning and improving)
Testing is context depending
Testing is basically context dependent.
Testing is done differently in different contexts, different kinds of sites are tested differently. For example, safety – critical software is tested differently from an e-commerce site.
Absence – of – errors fallacy
If the system built is unusable and does not fulfill the user’s needs and expectations then finding and fixing defects does not help.
Post a Comment