Common sense of software testing

The final purpose of the production software is to meet customer needs, we use customer demand as a standard to judge the quality of software, we believe that the specific meaning of software defects (software Bug) includes the following factors:
The software does not meet the needs of the customer function and performance, the software beyond the scope of customer needs, software emergence of customer demand is not tolerated errors, the use of software is not consistent with customer habits and work environment. Considering the design and other factors, we can also think that software defects can also include the software design does not conform to the specification, not in the specific conditions (funds, scope, etc.) to achieve the best. Unfortunately, many of us are more inclined to think of software defects as running-time problems, and that software testing is limited to program submission.

In the current domestic environment, we almost do not see a complete and accurate customer demand specification, to the customer's needs are constantly changing, the pursuit of perfect testing becomes unlikely. Therefore, as an excellent tester, the pursuit of the perfect software quality is our purpose, but clear the gap between the reality of software testing and the ideal, in software testing to learn to choose and concessions, the software testing is a benefit and no harm.

Here are some of the common sense of software testing, the understanding and use of these common sense will help us in the software testing to better grasp the scale of software testing.

• The test is incomplete (not fully tested)

Obviously, due to the incompleteness of software requirements, the combination of software logic paths, the large number of input data, and the multiplicity of results, even an extremely simple program, to exhaust all logical paths, all input data and validate all the results is very difficult thing. Let's give a simple example, for example, to ask for a greatest common divisor of two integers. Its input information is two positive integers. But if we test the numbers of the whole positive integer field, from its infinite number we can prove that such tests do not work in real life, and even if one day we can exhaust the program, we and our descendants are already dead. As a software test, we generally use equivalence class and boundary value analysis to carry out actual software testing, and find the minimum set of use cases as a necessary way to simplify our testing complexity.

• Testing is immune (software defect immunity)

Software defects, like viruses, have horrible "immunity," and the more tests a tester uses, the more immune it is, and the more difficult it is to find more software defects. We can introduce this conclusion by the mathematical probability theory. Assuming that there are 500 software defects in a 50000-line program and that these software errors are distributed evenly, a software flaw can be found on every 100 lines. We assume that testers use some method to find software defects in the energy of X hours/100 lines. According to this calculation, when there are 500 defects in the software, we need X hours to find a software defect, and when there are only 5 errors in the software, we need 100X hours for each software defect to be found. Practice has proved that the actual testing process is more stringent than the above assumptions, we must replace the different test methods and test data. This example also shows that a single approach to software testing is not efficient and fully targeted for all software defects, so software testing should be tested in as many ways as possible.

• Testing is a "generic concept" (full test)

I have always objected that software testing only exists after the program is completed. If only the stage after the program design phase is referred to as software testing, the demand phase and the design phase of the defects produced by the amplification effect will increase. This is very detrimental to ensuring software quality. Defects in demand, design defects are software defects, remember that "software defects have fertility". Software testing should span the entire software development process. Requirements validation (self-test) and design validation (self-test) can also count as a software test (recommended as a requirement test and design test). Software testing should be a generic concept that covers the entire software lifecycle so that every phase of the cycle can be tested. The test itself also needs to be evaluated by a third party (information system audit and software engineering supervision), i.e. the test itself should be tested to ensure the reliability and efficiency of the test itself. Otherwise, it is difficult to convincing.

It is also pointed out that software testing is the necessary condition to improve the quality of software products, but not sufficient conditions, software testing is the most direct and quickest way to improve product quality, but it is never a fundamental means.

• 80-20 Principles

80% of software defects often live in software 20% of space. This principle tells us that if you want to make the software test effective, remember to visit its high-risk multiple "lots" frequently. It is much more likely to find software defects there. This principle is of great significance for software testers to improve test efficiency and defect detection rate. Smart testers will quickly find more flaws based on this principle and foolish testers are still searching aimlessly.

Another case of the 80-20 principle is that we are able to detect and avoid 80% of software defects during the review of system analysis, system design, system implementation phase, test work, and then the system test can help us to find out the remaining defects of 80%, the last 5% Software defects may only be exposed after a wide and prolonged period of use by the user after the system is delivered. Because software testing can only guarantee as many software defects as possible, there is no guarantee that all software defects can be discovered.

80-20 principles can also be reflected in the automation of software testing come up, practice has proved that 80% of software defects can be found with the help of manual testing, 20% of software defects can be found by automated testing. Because of the cross-section between the two, there are still about 5% of software defects that need to be discovered and corrected by other means.

• Tested for Benefits

Why we need to implement software testing is to improve the project's quality and effectiveness ultimately to improve the overall effectiveness of the project. It is not difficult for us to draw the degree that we should master in implementing software testing. Software testing should find a balance between software testing costs and software quality benefits. This balance is the degree to which we should comply when we implement software testing. Unilateral pursuit will inevitably undermine the value and significance of software testing. Generally speaking, in software testing we should try to keep the software testing simple, do not complicate the software testing, the physicist Albert Einstein said is: Keep it simply but not too simplicity.

• The inevitability of defects

In software testing, not all software defects can be repaired due to the wrong relevance. Although some software defects can be repaired, we will inevitably introduce new software defects in the process of repair. Many software defects are contradictory, the disappearance of a contradiction will inevitably lead to the emergence of another contradiction. For example, when we solve the shortcomings of universality, it often leads to the defect of execution efficiency. In addition, in the repair process of defects, we often will be limited by time, cost and so on, so it is unable to effectively and completely repair all software defects. Therefore, to assess the importance of software defects, the scope of impact, choose a compromise solution or from non-software factors (such as improving hardware performance) to consider software defects as we face the software defects in a must face the fact.

• Software testing must have expected results

Testing without the expected results is unreasonable. Software defects are produced by comparison. This is just as there is no standard to measure. If we do not know beforehand or are not sure of the expected results, we must not understand the correctness of the test. It's easy to feel like Elephant general, many testers often rely on their own feelings to judge the occurrence of software defects, the result is often the specious things as the correct results to judge, so often the phenomenon of false test.

• The meaning of software testing-post-mortem analysis

The purpose of software testing is simply to discover flaws. If yes, I can assure you that a similar software flaw will occur in the next software test for a new project. As the old saying goes, "Those who do not know history will inevitably repeat the same". Without careful analysis of the results of the software test, we could not understand the cause of the defect and the response, the result is that we have to spend a lot of manpower and resources to find software defects again. Unfortunately, most test teams are not aware of this at the moment, and the test report lacks the test results analysis.