Good enough Testing
(Proper test)Chen nengji Original: a framework for good enough testing-James Bach
Good enough Testing
DefinitionSome testers may ask, "How do I know I have done enough ?" Unfortunately, there is no objective or rigorous answer to this question. However, we can identify the factors that should be taken into consideration before trying to answer a question. We can build at least an Inspiration Model around this issue. First, let's define what is good enough testing.
Good enough Testing
Is to form a full quality evaluation process, which is based on a reasonable price, used to support the wise and timely decision on the product.Break down the definition into four parts:
Product Quality Evaluation: What is the correctness and integrity of the product?
Test cost: How reasonable is the test consumption? Is it within the scope of the project? Is there a good return on the investment in testing? For example, is there any additional information available after each test?
Decision:Is the product quality assessment good for projects and businesses?
Timeliness: Is the timeliness of evaluation and decision fast enough to play a role? Some testers are notified that the tests they perform will not affect the product release decisions. If so, the test should be stopped. On the contrary, if continuing testing will provide technical support or provide basic support for some other types of decisions of the company, continue testing. Because tests are linked to decisions to be made, or some data is provided for future use. Some tests are performed at the request of an organization or some so-called authoritative people. Some tests are executed only because the test plan is developed. This is contrary to the good enough testing principle. Good enough testing is a conscious and purposeful test, not a superstitious or ritual. In fact, the tests mentioned in many developed test plans can be discarded because they have no impact on test projects or stakeholders. Many times, the test plan is written because some people say, "in textbooks, we should have such a test ".
Composition of evaluation1. How do we assess and report product quality? Are we sure the quality assessment is verifiable? Are we clear about the express and implied product requirements? How quickly can we find important problems in the product after the product is created? Does our test cover all aspects of the products to be covered? Have we applied sufficient test method types or used sufficient sources of quality information to eliminate test coverage errors? Is there a possibility of a major problem we don't know in the product? Is there a problem that should have been detected by the test but not discovered by the tester but reported by other channels? 2. How much test cost is consumed? What is the test price we can afford? Can we eliminate unnecessary redundancy from test coverage? What makes test execution difficult (high cost )? Can product testability be improved? Is there any tool or technology that can make the test process more efficient? Should I test it earlier or later? In which case is the overall testing cost lower? 3. Check the role of tests in decision-making. Does the test process clearly determine the decisions that managers, developers, or other customers need to make? Do the testing process focus on potential product and project risks? Does the test process depend on the change control process and project management? Is the test report submitted in time? Does the test report communicate in an easy-to-understand manner? Is the test process the same as the test result? Are we reporting the basis of evaluation and integrating our confidence? Does the testing process provide services for technical support, release, market, or any other business process that requires quality assessment? 4. Whether or not the above three aspects are time-driven. So there is a problem: we never have enough time to do everything, so everything we do is a race against time.
Integrated analysis1. How good is our test? Based on the previous questions, consider whether there are urgent problems in our current testing process? Is our testing process adequate? Is it possible to give an early warning to the project management when the product quality fails to reach the expected goal? Are there some potential types of problems that are intolerable? If so, are we confident that our testing process can identify and locate these problems? 2. Is it worth improving? What policies can we use to improve testing? Are we capable of applying these test policies? Do we know how to apply it? How much will the improvement test consume? How troublesome will it be? Is it the best way to use resources? Can this problem be solved temporarily? Can improvements be made within an acceptable time range? Will improvements cause negative effects, introduce new bugs, and affect morale? Will improvements bring about significant differences? If the test Manager is unwilling to face the fact that "A test without any omissions is impossible", he will choose an impossible test. The purpose of good enough testing is to help software testing engineers get rid of the Rules, subjective and passive situations of testing, and apply structured and rational methods to complex and multidimensional problem sets.
