Software Testing Principles

Software testing is an extremely creative and intellectually challenging task. When testing follows the principles given below, the creative element of test design and execution rivals any of the preceding software development steps.

Testing must be done by an independent party.
Testing should not be performed by the person or team that developed the software since they tend to defend the correctness of the program. The developer is driven by delivery and he will try to finish the testing as early as possible. The developer is gentle in testing his code and has a soft corner for his code. The independent tester is driven by quality and will try to break the code. Hence testing should be done by an independent person.

Assign best personnel to the task.
Because testing requires high creativity and responsibility only the best personnel must be assigned to design, implement, and analyze test cases, test data and test results. Also note that from point 1, the testing is being done by an independent tester, the system is new to him and he has to understand the entire system to test it. It is possible to find bugs and issues with software only when you know the system thoroughly.

Testing should not be planned under the tacit assumption that no errors will be found.
Testing is the process of executing a program with the intent of finding errors. Good testing will find bugs… and testing is never complete, it is infinite. There should be no assumption that the software has no errors. Such an assumption would leave tremendous amount of holes in the system.

Test for invalid and unexpected input conditions as well as valid conditions.
The program should generate correct results when a valid input is given, this is called as positive testing; Also the software should give correct error messages when an invalid test is encountered, this is called as negative testing. We need to give a different range of inputs with varying sets of values. For example, if the input field is taking a positive integer, we should try with all sorts of integers, positive, negative, zero, large positive, large negative etc. Also we should try giving a character, string etc and the expect the correct error message.

The probability of the existence of more errors in a module or group of modules is directly proportional to the number of errors already found.
If you find a bug in a particular module, the developers just tend to resolve that issue and close the bug. But there is a more probability that there will be more issues in that area. You need to look around, why that particular bug is present and look for similar issues in that module, you are going to hit many issues.

Keep software static during test.
The program must not be modified during the implementation of the set of designed test cases. Modifying the program while the testing has started will leave a lot of loop holes in the testing; you would have finished testing module A and started testing on module B, but by that time, module A would have changed and the changes are not tested!!!

Document test cases and test results.
This is very important for testers, you need to document the test cases, which can be used for later testing, may be for the next release. The test results should be documented so that they can used for analyzing if required at a later stage.

Provide expected test results if possible.

A necessary part of test documentation is the specification of expected results, even if providing such results is impractical. Using the expected results you can verify the software which is under test and declare whether the software meets the expectations or not.