A number of testing principles have been suggested over the years. Here is some of general guidelines common for all testing.
Principle 1: Presence of defects.
Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the number of probability of undiscovered defects remaining in the software, but, even if no defects are found , it is not a proof of correctness.
Principle 2: Exhaustive input testing.
To be sure of finding all defects, one has to test using not only all valid inputs, but all possible inputs.So infinite numbers of test cases may have to be produced. So testing everything (All combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, risk analysis and priorities should be used focus testing efforts.
Principle 3: Testing is creative and difficult.
Testing is not simple because extensive domain knowledge is required. Large software systems are also very complex in nature. Testing requires insight & knowledge. Creativity & experience required for effective testing.
Principle 4: Early testing.
Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives. Testing early will reduce the error which will prevent the defects at later stage. Cost of fixing the errors/defects at a later stag is higher than fixing it at an early stage. The cost of rectifying defects in the later stages climbs logarithmically and not linearly.
Principle 5: Defect clustering.
A small number of modules contain most of the defects discovered during pre-release testing, or are responsible for the most operational failures.
Principle 6: Pesticide paradox.
If the same tests are repeated over and over again, eventually the same set of test cases will no longer find new defects. To overcome this pesticide paradox, the test cases need to be regularly reviewed and revised, and new different test cases need to be written to exercise different parts of the software or system to potentially find more defects.
Principle 7: Testing must be planned. (If you fail to plan, then plan to fail)
Adhoc testing does not give confidence on software quality. Document the test objectives, approach and the resources in a test plan document.
Principle 8: Context dependent.
Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce application.
Principle 9: Absense-of-errors fallacy.
Finding & fixing defects does not help if the system built is unusable and does not fulfill the users needs and expectations.