# When do you know, how much testing is enough?

DevFeed: [When do you know, how much testing is enough?](<https://devfeed.tech/articles/when-do-you-know-how-much-testing-is-enough-31964.md>)

Original publisher: [Read original article](<https://tech.finn.no2012/05/21/when-do-you-know-how-much-testing-is-enough/>)

Author: vivek

Published: 2012-05-21T11:56:43Z

Content type: opinion

Language: en

Sources: [Finn.no](<https://devfeed.tech/sources/finn-no.md>)

Topics: [Testing](<https://devfeed.tech/topics/testing.md>), [test](<https://devfeed.tech/topics/test.md>)

Tags: [bugs](<https://devfeed.tech/tags/bugs.md>), [defects](<https://devfeed.tech/tags/defects.md>), [deployment](<https://devfeed.tech/tags/deployment.md>), [developers](<https://devfeed.tech/tags/developers.md>), [quality](<https://devfeed.tech/tags/quality.md>), [release](<https://devfeed.tech/tags/release.md>), [signal](<https://devfeed.tech/tags/signal.md>), [testing](<https://devfeed.tech/tags/testing.md>), [tests](<https://devfeed.tech/tags/tests.md>)

## AI overview

The article discusses how to judge whether testing is sufficient before release. It recommends continuing to test when defects are found or important functionality has received little coverage, while stopping may be reasonable when sustained testing of a particular area finds no new defects. It warns that untested features and confidence based only on successful compilation can create false confidence.

## Source excerpt

Let me begin with an example, from every days scenario at work. You are at the end of the sprint and have some errors reported. You think that the quality of code and tests are good enough for release. Based on this the reported bugs the failures are minor and won't have big impact after fixing them. But the reality may be different, that you really are on opposite ends of the quality. The code and test quality is low, and the reported tests are few or no bugs. Your worst case scenario could be that deployment/release will go very bad and can be very expensive in a technical or business nature. It's important to evaluate the possibility of finding more defects based on results you have gathered so far. The key is to analyze your rapport thoroughly because: If you have just found a defect, this is a signal to keep testing. It may seem counter-intuitive but in general the more defects you find the more likely it is that there are additional defects. If you have only exercised a small portion of the overall functionality and have found defects, then this is a signal to continue testing. If you have been testing a particular piece of functionality for a while and are not finding any new defects, then this is a signal for you to stop testing. How much of the system's functionality have you tested? If there are significant features that are mostly or entirely not tested, then you will likely not be prepared to recommend it is good to go. False confidence is a very real danger. This is especially true for developers. I have seen or heard of many who have an unrealistically high level of confidence that their code works, in some cases without any testing whatsoever. As a specific example, I have heard developers state that if their code compiles, it is good enough to be promoted to acceptance testing. Testing by definition is comparing an expected result to an observed result. So it should be easy to answer the question how much testing is enough? But the answer could be ba