Some questions during the test (defect detection rate, test end criteria, etc.)

Others ask questions of the post, casually hit some, talk about their views.

Original posts: http://bbs.51testing.com/thread-475716-1-1.html

1. How to improve the defect detection rate in the test process, so that the test problem as far as possible in the first to second round of discovery, reduce the number of bug per round.
Defect detection rate, more to understand the program and business, in other words, whether you understand the development of software and development of people. If there is unit testing, integration testing, and so on, to the testers, most of the problems should be solved, but now very few can do, more is the developer finished on the test, the early lack of or even no documentation, the level of development personnel is different, the sense of responsibility is the day difference.
Under such conditions, the testers can only guarantee their own parts, such as more research on the existing documents, more detailed understanding of the needs, the collection of problems, and so on.
Improve the defect detection rate, more not testing here, is a whole process to better guarantee. Testers do not guarantee the quality of the software, that is the QA thing, the test of responsibility in discovering the defects of the program.
In fact, most of the situation, software development, quality is fixed, testing is just leaking in the bucket, tell the bucket where there are holes, everywhere dozen patches.

2. How to calculate the end of a round of testing, you can reach the test end standard.
The end of a round of tests and the end of the test is different. Usually there are use cases, the use cases executed once, you can say that a round of testing completed; There is no test case, the test of each module is a round.
The test end standards look at the company's rules. For example, there is no fatal defect, the remaining defects do not affect the software function, etc., look at the company's standards. There is no standard, testing and development tug-of-the-buck, usually under the pressure of progress, slackened loose the problem of the software is gone. Anyway, most of the software, there are problems are mostly able to deal with the past. In fact, the pressure of customers is much more effective than testing, and testing usually does not have much power to control the direction of the software.

3. How can we find out how to be early in the case of more concealed defects?
As the first problem, since it is hidden, then you need to understand the requirements and software. If you don't find it, you don't know it, and there's nothing to hide. Actually feel the hidden flaw more is the tester self-cool, say look, so tortuous problem I find it. Testers feel the hidden problem, and the odds of a customer finding it are even smaller.
Hidden problems, usually test cases and other methods are not very effective, with exploratory such testing methods, to deal with such problems should be more efficient.