Editing Software testing (section)

== Goals ==

Software testing is typically goal driven.

=== Finding bugs ===

Software testing typically includes handling software bugs {{endash}} a defect in the [[source code|code]] that causes an undesirable result.<ref name="IEEEglossary">{{Citation |date=1990 |publisher=IEEE |doi=10.1109/IEEESTD.1990.101064 |isbn=978-1-55937-067-7 |title=IEEE Standard Glossary of Software Engineering Terminology }}</ref>{{rp|31}} Bugs generally slow testing progress and involve [[programmer]] assistance to [[debug]] and fix.

Not all defects cause a failure. For example, a defect in [[dead code]] will not be considered a failure.

A defect that does not cause failure at one point in time may lead to failure later due to environmental changes. Examples of environment change include running on new [[computer hardware]], changes in [[source data|data]], and interacting with different software.<ref>{{Cite web |date=March 31, 2011 |title=Certified Tester Foundation Level Syllabus |url=https://www.istqb.org/downloads/send/2-foundation-level-documents/3-foundation-level-syllabus-2011.html |access-date=December 15, 2017 |publisher=[[International Software Testing Qualifications Board]] |at=Section 1.1.2 |format=pdf |archive-date=October 28, 2017 |archive-url=https://web.archive.org/web/20171028051659/http://www.istqb.org/downloads/send/2-foundation-level-documents/3-foundation-level-syllabus-2011.html |url-status=dead }}</ref>

A single defect may result in multiple failure symptoms.

=== Ensuring requirements are satisfied ===

Software testing may involve a Requirements gap {{endash}} omission from the design for a requirement.<ref name="kolawa" />{{rp|426}} Requirement gaps can often be [[non-functional requirements]] such as [[software testability|testability]], [[scalability]], [[maintainability]], [[Computer performance|performance]], and [[Computer security|security]].

=== Code coverage ===

A fundamental limitation of software testing is that testing under ''all'' combinations of inputs and preconditions (initial state) is not feasible, even with a simple product.<ref name="Kaner2" />{{rp|17–18}}<ref>{{Cite web |date=July 1, 2005 |title=Certified Tester Foundation Level Syllabus |url=http://www.bcs.org/upload/pdf/istqbsyll.pdf |access-date=December 15, 2017 |publisher=[[International Software Testing Qualifications Board]] |at=Principle 2, Section 1.3 |archive-date=December 17, 2008 |archive-url=https://web.archive.org/web/20081217060536/http://www.bcs.org/upload/pdf/istqbsyll.pdf |url-status=dead }}</ref> 
Defects that manifest in unusual conditions are difficult to find in testing. Also, [[Non-functional requirements|non-functional]] dimensions of quality (how it is supposed to ''be'' versus what it is supposed to ''do'') {{endash}} [[usability]], [[scalability]], [[Computer performance|performance]], [[Backward compatibility|compatibility]], and [[reliability (engineering)|reliability]] {{endash}} can be subjective; something that constitutes sufficient value to one person may not to another.

Although testing for every possible input is not feasible, testing can use [[combinatorics]] to maximize coverage while minimizing tests.<ref>{{Cite conference |last1=Ramler |first1=Rudolf |last2=Kopetzky |first2=Theodorich |last3=Platz |first3=Wolfgang |date=April 17, 2012 |title=Combinatorial Test Design in the TOSCA Testsuite: Lessons Learned and Practical Implications |conference=IEEE Fifth International Conference on Software Testing and Validation (ICST) |location=Montreal, QC, Canada |doi=10.1109/ICST.2012.142}}</ref>