Psychology of software testing:
One of the major causes of poor test execution is that most programmers have mistakenly defined the test term from the very beginning. They may think that:
- "Software testing is the process of proving that the software does not have an error"
- "The purpose of software testing is to prove that the software can correctly complete its intended functions"
- "Software testing is a process of building up 'confidence that the software has done what it should do"
These definitions are all put before the horse.
For testing, a more appropriate definition should be:
"Testing is the process of executing a program to detect errors"
We can look at a patient's seeing a doctor. The patient goes to the doctor because the patient is not feeling well. If the doctor has performed some lab tests on the patient but has not diagnosed any cause, we will not consider these lab tests as "successful ". The reason is that the "unsuccessful" test is because the patient has paid an expensive medical fee, and the patient still exists. The patient will therefore question the Doctor's diagnostic capabilities. However, if the experiment detects that the patient is diagnosed as a gastric ulcer, the test is "successful" and the doctor can take appropriate treatment. Therefore, the medical community uses "successful" or "unsuccessful" to express what is appropriate. We can move on to software testing. When we start to test a program, it is like our patients.
Economics of software testing:
Can software testing detect "all" errors. The answer is no.
Some strategies should be established before the test starts to meet the challenges of test economics. Black box testing and white box testing are two of the most common strategies.
1. Black box testing
It is also called a data-driven test or an input/output-driven test. The purpose of the test is completely unrelated to the internal mechanism and structure of the program.
2. white box testing
It is also called a logic-driven test.
Principles of software testing:
- A required part of a test case is to define the expected output or acceptance.
- Programmers should avoid testing their own programs
- Organizations that write software should not test their own software.
- The execution results of each test should be thoroughly checked
- Test cases should be written based not only on valid and expected inputs, but also on invalid and unexpected inputs.
- Check whether the program is "not doing what it should do" is only half of the test, the other half of the test is to check whether the program "does what it shouldn't do"
- Do not discard test cases unless the software is a one-time software.
- We should not acquiesce to the assumption that no errors will be found during testing.
- There is more possibility of errors in a part of the program, which is proportional to the number of errors found in this part.
- Software testing is a very creative and intellectual challenging job.
The art of testing: Psychology and economics of software testing