1 - Testing only confirms the existence of the errors they find.
When you perform a set of tests and a series of errors are detected, no one can assure you that there are no more bugs in the software that the test set does not detect, you only know that the detected errors exist.
2 - It is impossible, almost infinite, to prove all possible cases.
The number of possible cases to test to find errors in software testing can be a large number, it can probably be infinite, so you must assume that not all cases can be tested.
In addition, any correction that you apply to the software found in the test battery to solve detected bugs will add new variables and these will cause the number of cases to be tested to increase again. Sad but true!
3 - The Pesticide Paradox: The effectiveness of your test battery for errors decreases over time
This means that like a pesticide, a test suite will catch the bugs it was designed to but will not find the bugs it was not built to catch.
The automation of test execution loses its value over time since the errors it detects will not appear but it will not alert us about others that have been introduced and for which it was not designed.
4 - Bugs hide behind other bugs.
Bugs are usually hidden behind other bugs, as they tend to be grouped together when they appear. This makes repeating tests an investment in time that must be taken into account in the initial budget of the project.
5 - Error-free software is a lie.
If a battery of tests in your Testing phase does not show any errors or Bugs, that is, everything has gone well, it does not mean in any case that the software does not present errors, it is rather that in said tests they have not been able to detect them. There is no software without errors.
Finally I quote a phrase that I don't remember where I read but it is very true.
"A software that does not present errors is surely a software that no one uses."
Article source
https://tcagley.wordpress.com/2014/05/15/testing-principles-part-1-this-is-not-pokemon/
