[to] the triple state of the test

The first level of testing: around the bug to "conscious decision action, action decisions" is a well-known famous in management.

　　The first realm of testing : Around bugs

"Conscious decision action, action decision result" is a well-known quote in management. In the first few years of testing, the author did not have this consciousness, and did not take the initiative to think about this problem, but with a project task, a pile of experience, slowly realize that this sentence is also suitable for the test work realm understanding. "Mentality decides destiny", "Attitude decides everything", there are many famous scholars have written this aspect of the book, basically has become our undeniable truth, but to really apply in their own work life, I am afraid it is not so simple. Admittedly, the test work, in addition to the need to have excellent testing technology, but also must have the right test mentality, it is these mentality awareness around your daily work. Different mentality reflects the height of different test realms, and finally shows different results.

Turning around the bug is the first of the tests in the triple realm. Summed up, it can be divided into three stages, first, found the bug; second, locate the bug; third, close the bug. The requirements for testers in these three stages are not only technically necessary, but also higher in comprehensive quality. The three phases are interlocking between each other. Until the end of the bug's life cycle. The three phases around the bug turn to the tester 's requirements and bugs are found to the closed life cycle. As shown in 2-1.

Figure 2-1 The three advanced graphs around a bug

Talking about the three stages around the bug, I can't help but think of the three realms of life that the famous scholar Wang Guowei in "Human Cihua" mentioned in the world:

"Last night the West wind wither Green tree, alone on high-rise, looking at the end of the road."

"Emaciated end not regret, for Iraq to eliminate people haggard."

"In the crowd to find him 1100 degrees, suddenly look back, that person is in the lights dim place."

Think about it and feel the similarities between them.

The first heavy "last night westerly wither Green tree, alone on the high-rise, look at the end of the road" is said "ancient and modern into the big business, Brainiac, first to establish a clear goal, even if long road, but also determined to go down this road." This is a painful moment when one finds the ideal in solitude and seeks the foothold of life. " The first order around the bug to "find bugs", the same first must have clear and clear goals, the process of finding the bug is long, repeated, boring is the characteristics of the work, but in order to achieve the goal "long road, also have to stick to go" until a heap of bugs. Especially for some even serious bugs, the process of reproducing bugs is really like a needle in the haystack, but persistence is victory. The author has spent nearly 1 months in a project to reproduce and solve a serious problem, finally in close cooperation with the developers , finally found the root cause of the problem.

Second heavy "emaciated end not regret, for Iraq to eliminate people gaunt" is to say "persistent pursuit, selfless struggle, until gaunt and thin, even clothes have become lenient, this all efforts are for the heart of the dream." Corresponds to the second-order "fixed bug" that surrounds the bug in soft measurement. This stage not only technically put forward higher requirements, but also have to study hard, hunt down to the end, do not hit the south wall does not turn back the persistent spirit, until the cause of the problem to understand the Chu just give up. In the current testing field in China, most companies do not require testers to do this step, but in foreign countries, especially some well-known large companies, such as Microsoft, almost all testers have the skills of deep debugging procedures. In addition to including the shortest path to reproduce the problem, but also to analyze the possible results of the problem (such as the analysis of the bug will affect which modules), and even to the developer to propose a solution. Obviously, this step requires testers to have higher design analysis, code debugging and problem solving skills than developers. Readers, see here, for some of the test professional online often see "testers should understand programming " This problem has been relieved in the bosom.

The third heavy "in the crowd to find him 1100 degrees, suddenly look back, the person is in the lights dim place." This stage refers to through continuous tempering, many times of failure, a moment suddenly connected to a point, the understanding of the true meaning, found that they want to the original in their own side or understanding after the heart. In the eyes of others, his "suddenly look back" is how accidental and lucky, but the back of the diligent, ordinary accumulation of deep, but also ordinary people can persist, can imagine it? At this time, whether the secular goals have been achieved is no longer important, it is important that the liberation of the soul and the spiritual belonging. corresponding to the third order around the bug to "close the bug", if only from the literal understanding, very simple, is not developed to solve the bug, return to the bug, and then close the bug. If so, I think this concept still belongs to the first order. Third-order close bug, refers to the tester to submit a bug, to have the initiative to promote the developer to solve the problem, and help them solve, only the problem solved, the quality of the software to improve, the tester's ultimate goal can be achieved. Some of the questions submitted are strictly not a bug, but a design flaw , so what should testers do? Proactively convene relevant experts to conduct risk analysis of their impact, and follow up the entire resolution of this issue, if the risk points involve other professional changes (such as embedded software involving hardware , machinery and other aspects of knowledge), may need to set up a special problem solving team to comprehensively solve this problem, until the professional direction of the problem solved in place, the return verification completed, this bug can be closed. From the point of view of the life cycle of a bug, a bug is a reasonable, complete process, from the point of origin found, to the end of closure, as shown in 2-2. But to reach this level, it is likely that a large part of the work has been completely out of the pure software testing level of work, but the ultimate goal of testing is to give users a high-quality, trustworthy product? We need to have such an atmosphere of mind, in order to make product testing work more far-reaching and wider.

In the following case, the three stages around the bug are introduced.

Figure 2-2 Bug life cycle curve closed loop diagram

The second realm of testing: standing on top of bugs

Is the value of testing just a bug? By "Standing on Bugs" test the introduction of the second realm, hoping to help readers understand correctly what the real value of the test, how to operate in the actual work to reflect these values. Different ideas will lead the testers to move in different directions, "standing on bugs" can broaden the field of view of the testers, find more to fully reflect the test value of the test chain, so that testers to make a greater contribution to the success of the project, resulting in a wider range of test success.

The value of testing is more than just finding bugs

When it comes to testing, you'll think of bugs right away. Is testing just to find bugs? This is a question that deserves our consideration.

Starting with the most basic definition of software testing, as early as 1979 J. In the book "The Art of Software Testing", Myers mentions:

1, the purpose of software testing is to find the bug early.

2. A successful test is the detection of bugs that have not been discovered so far.

In short, the test is to find the bug, the test does not have to work around the bug to expand, 2-8. The more bugs the test finds, the more proud and fulfilling the testers are, and the idea is almost ingrained in our minds, and does the test have anything else to do but find bugs?

Figure 2-3 A bug-centric test mechanism has been found

Found a lot of bugs, testers happy, but the boss is certainly not happy. Obviously, in order to solve these bugs, he has to pay more, including the salaries of developers and testers, and, more seriously, the time it takes for the product to be delivered to the market. Shopping malls such as battlefield, time is money, time can bring more market space for the product, to win more profits for the enterprise. Understanding these business knowledge can help us do the right thing and do things right. Aware of this, I believe that test friends will no longer be a bug has not been resolved, the version is listed and brooding. Testers should jump out of the circle of complacency about bugs, see the project as a whole, and stand in the company's shoes to test what they can do. Only the success of the project, the company can obtain profits, and ultimately achieve the goal of both employees and the company.

Quality, cost and time are the three elements of project management . They are like three pillars, steady, that is, good quality, low cost, short duration, such projects are of course the project manager would like to. But they are contradictory and visually, they are like a equilateral triangle, 2-4. For any one of these elements to be improperly handled, the triangular relationship of ternary will become unstable, which will bring risks to the success of the project.

Figure 2-4 Test and project management features diagram

The software testing team is one of the members of the entire project team family, checking the software quality to find bugs as early and as many as possible. This is also the foundation of software testing, is the quality of the project to contribute to the place. So in the cost and time control, what can the test do, how to do it? That is how the tests mentioned earlier do the right thing with the success of the project and do things right.

Tips:

1, do the right thing and do things correctly

2, do the right thing is to maximize the interests of enterprises, rather than stand in the individual and small groups of the position to do things, is not afraid to take responsibility, to push things to others. Ask us to choose among many possibilities, identify what is right, what is the most direct, the most feasible way of doing things, and maximize the efficiency of the business as a standard.

3, the right thing to do, is to drive the specific work of the people in accordance with the leadership of the advice to do things, and not to consider whether it is in line with the principle of maximizing enterprise efficiency.

For testing, doing the right thing is to stand on the user's point of view, do common functions (modules) focus on testing, and avoid the very use of the function of excessive testing, waste of costs, including manpower and time investment. To do the right thing is to use a reasonable and comprehensive test method to verify whether the software meets the user's requirements , and does not want to, of course, be verified by illegal operation or backdoor that the user simply cannot use. The following is about the 2-8 principles of software testing, through this 2-8 principle, you can make software testing in the cost and time of the project to maximize the effectiveness of the application.

For everyone in the daily life often encountered examples, such as often see the ads say, now the mobile phone software features how powerful, how rich, but each function users use the same frequency? The answer is No. This has the 2-8 principle of the focus of software testing scope, that is, to put 80% of the focus on testing 20% of the key functions. From a user's point of view, this is worthwhile and needs to be done.

First, analyze what features are central and important to users in our software systems, and then arrange for the appropriate test engineers to be responsible for these modules. Design the test plan, use case to focus on review, test execution process focus on tracking. Every time a software release is released, even if you do not change the code for this section, they are also tested for regression (this regression requires strategies and methods) because they are too important to allow for errors.

The following is a detailed description of the software test 2-8 principles.

1.8% of errors are caused by 20% of the modules

Simple, easy modules or features rarely introduce too many bugs, while some key modules with complex logic often cause system 80% errors. Only the key modules are stable, and the whole system can be truly robust and stable.

This principle for testing is to stand in the user's perspective (rather than the development of the implementation of the angle), the right choice of important functional modules as the focus of the test, do not deviate from the direction.

2.8% of the test cost is spent in 20% of the software module

When designing test Cases , it is often time to measure the work of engineers with the number of use cases of Nissan. The number of use cases is related to the demand, while the requirement description of the software architecture design is often relatively small. In this case, the design of the test case is particularly necessary in conjunction with the software's outline design, detailed design together. If a use case designer is trying to get to the number of use cases by using a large number of replication use cases, modifying individual words instead of really designing efficient test Cases , then using such inefficient or even more use cases to deal with complex 20% core modules, During the test execution, some key bugs will not be found.

3.8% of the test time is spent in 20% of the software modules

For complex modules, pre-test design and thinking can be time-consuming, and the amount of use cases produced may not be significant. For complex systems, especially for new systems, you must be willing to devote sufficient time to prioritize design, the shorter the upfront plan, the less time the use case is designed, and the greater the risk later.

After the project progresses to a certain stage, the increase of manpower does not necessarily solve the problem of shortening the time. For example, if complex and core modules begin to perform tests later in the project, because of the number of bugs and the need for the project to stabilize the version in a short time, it is common practice to add people. The recruits, however, need a period of familiarity and, if necessary, veterans to take them, which in turn will affect the veteran's work. Other performance tests, automated testing work is only as stable as the version will have a better effect.

The third realm of testing: Challenge Zero defect

Confucius said, "There is no foresight, there will be immediate worries", used in software testing, what is the meaning of it? It can be understood that if we do not solve the problem from the root cause of the problem, the test is only to find the bug, all the way to find the bug, the bug is always found, the consciousness will fall into the "Never Daylight" However, a small number of testers really hope that the software has more problems (are disruptive), so that you can submit more bugs, that the performance is better than not to submit a number of bugs. Coincidentally, a small part of the developers also take their own procedural errors as a matter of course, and even some people will play abuse to say "software if there is no bug, the testers will not be unemployed." It's like singing a double reed play. The whole process of software development, the bug is a matter of course to exist, is this it? The source of software crisis in software engineering can only be controlled by the means of finding bugs?

In fact, we all know that the generation of any bug is a source, which includes the design of the requirements, the design of the software (including the writing of the Code), and so on. Compared with the front-end design, the test is the verification after the event, is a "blocking" the vulnerability of the measures. However, in actual work, time and cost do not allow us to block all bugs. Japanese quality master Tiankou a good saying "quality is designed, not tested." If we can become passive as the initiative, before the design, the design of the precautionary measures for the design of high-quality software to lay a solid foundation, this is what this section intends to introduce to readers the third realm of testing: Challenge zero defect.

1. Prevention and blocking of defects

Almost every time I interview a test engineer , I will ask a question like: "The module you are responsible for testing, whether there is a leak test situation", almost every candidate has answered "yes". In the face of complex software, complex operating environment, in a limited time to carry out testing activities, to achieve a real 0 bug is not possible, is also unrealistic. But these are not grounds, all testing activities are purposeful business activities, each company has its own set of standards or principles for testing. Although the leak test is unavoidable, but it is not said that the leakage test is a normal phenomenon or should be phenomenon, the leakage of the problem if it is beyond the company can accept the principle, it is not normal phenomenon, it is necessary to carry out the leakage test analysis. To carry out the leakage analysis activities (special attention is that it is not the intervention of the leakage of personnel), its main purpose is to analyze the past lessons, to identify the root cause of the problem, the analysis of the test which link work is missing in order to come up with a circumvention of actionable measures out.

When the tester is leaking analysis, the problem is unavoidable. Software is designed by developers, so the leakage analysis activities are not only the presence of developers, and sometimes involve the needs of designers. As for the trace analysis, here is an interesting analogy between development and testing, like building a dam, 2?11. Developer Design software is like building a dam, if the dam is structurally problematic, when the flood strikes, it may not just be a partial leak, but a direct burst of water, like software crashes. High dams, there will inevitably be leaking holes, or seepage of small holes, as if the software exists in the small bug. The more difficult it is to find the leakage or seepage problem at the base of the embankment, the more costly the solution is.

In the design to build a solid structure, there is no loophole of course better, this is a precaution. If beyond the boundaries of prevention, the design brought out of the hole in the hole left to test, it had to hold a variety of magnifying glass (using various methods) to detect, to snare a variety of deep shallow, large and small problems, and finally through the "patching" way, blocking the "devastated" on the dam.

Fig. 2-5 anti-blocking of defects and anti-blocking image understanding of dams

2, the defect of the anti-blocking

In the area of prevention and blocking of defects, testing is the intermediate role of discovering problems, telling developers where they are leaking or seeping. The work of preventing and plugging is done by the people who build the dike. Of course, the prevention is active, plugging is passive, active into passive, the middle has experienced the investment of resources and time, admittedly even the same Bug, their cost is completely different. The more it gets in the back, the bigger the impact, the greater the price, 2-6 (excerpted from the Code encyclopedia) is an example of increasing the cost of testing based on the phase of the defect.

Figure 2-6 The average cost of correcting the same defect based on the introduction and detection time of the defect

As shown in 2-6 is a flaw introduced in the requirements phase. If this problem is discovered immediately, the cost of the modification is only $1, but if it is found during the system testing phase, the cost of the modification is increased by 10 times times. Even worse, if the issue is discovered by the client after release, it will cost 10 times times more or even 100 times times. The longer the defect is in the system, the greater the cost of resolving it, because the longer the time, the higher the costs of development and tester modification, and also the large area of user-side upgrades.

[to] the triple state of the test