Content deleted Content added
grammar, style, added links |
review: combine short related paragraphs. rm unnec qualifier. |
||
Line 135:
=== Specification ===
Some{{who?|date=May 2025}} contend that writing a [[program specification]], which states the intended behavior of a program, can prevent bugs. Others{{who?|date=May 2025}}, however, contend that formal specifications are impractical for anything but the shortest programs, because of problems of [[combinatorial explosion]] and [[Nondeterministic algorithm|indeterminacy]].
=== Software testing ===
One goal of [[software testing]] is to find bugs. Measurements during testing can provide an estimate of the number of likely bugs remaining. This becomes more reliable the longer a product is tested and developed.{{citation needed|date=February 2017}}▼
▲Measurements during testing can provide an estimate of the number of likely bugs remaining. This becomes more reliable the longer a product is tested and developed.{{citation needed|date=February 2017}}
=== Agile practices ===
Line 147 ⟶ 145:
[[Agile software development]] may involve frequent software releases with relatively small changes. Defects are revealed by user feedback.
With [[test-driven development]] (TDD), [[unit test]]s are written while writing the production code, and the production code is not considered complete until all tests have been written and complete successfully.
=== Static analysis ===
Tools for [[static code analysis]] help developers by inspecting the program text beyond the compiler's capabilities to spot potential problems. Although in general the problem of finding all programming errors given a specification is not solvable (see [[halting problem]]), these tools exploit the fact that human programmers tend to make certain kinds of simple mistakes
=== Instrumentation ===
| |||