Content deleted Content added
Undid revision 1248776107 by MILLIONDOX (talk) unsourced |
|||
Line 5:
[[File:TestingCup-Polish-Championship-in-Software-Testing-Katowice-2016.jpg|thumb|TestingCup {{endash}} Polish Championship in Software Testing, [[Katowice]], May 2016]]
'''Software testing''' is the act of checking whether [[software]] satisfies expectations.
Software testing can provide objective, independent information about the [[Quality (business)|quality]] of software and the [[risk]] of its failure to a [[User (computing)|user]] or sponsor.<ref name="Kaner 1">{{Cite conference |last=Kaner |first=Cem |author-link=Cem Kaner |date=November 17, 2006 |title=Exploratory Testing |url=https://kaner.com/pdfs/ETatQAI.pdf |conference=Quality Assurance Institute Worldwide Annual Software Testing Conference |___location=Orlando, FL |access-date=November 22, 2014}}</ref>
Software testing can determine the [[Correctness (computer science)|correctness]] of software for specific [[Scenario (computing)|scenarios]], but cannot determine correctness for all scenarios.<ref name="pan">{{Cite web |last=Pan |first=Jiantao |date=Spring 1999 |title=Software Testing |url=http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/ |access-date=November 21, 2017 |publisher=Carnegie Mellon University |type=coursework}}</ref>
Based on the criteria for measuring correctness from an [[test oracle|oracle]], software testing employs principles and mechanisms that might recognize a problem. Examples of oracles include: [[specification]]s, [[Design by Contract|contracts]],<ref>{{Cite conference |last1=Leitner |first1=Andreas |last2=Ciupa |first2=Ilinca |last3=Oriol |first3=Manuel |last4=Meyer |first4=Bertrand |author-link4=Bertrand Meyer |last5=Fiva |first5=Arno |date=September 2007 |title=Contract Driven Development = Test Driven Development – Writing Test Cases |url=http://se.inf.ethz.ch/people/leitner/publications/cdd_leitner_esec_fse_2007.pdf |conference=ESEC/FSE'07: European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering 2007 |___location=Dubrovnik, Croatia |access-date=December 8, 2017}}</ref> comparable products, past versions of the same product, inferences about intended or expected purpose, user or customer expectations, relevant standards, applicable laws.
Line 25:
A study conducted by [[NIST]] in 2002 reported that software bugs cost the U.S. economy $59.5 billion annually. More than a third of this cost could be avoided, if better software testing was performed.<ref>{{Cite web |date=May 2002 |title=The Economic Impacts of Inadequate Infrastructure for Software Testing |url=https://www.nist.gov/director/planning/upload/report02-3.pdf |access-date=December 19, 2017 |publisher=[[National Institute of Standards and Technology]]}}</ref>{{Dubious|NIST study| date = September 2014}}
[[Outsourcing]] software testing because of costs is very common, with China, the Philippines, and India being preferred destinations.{{
== History ==
Line 39:
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 later occur 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.
Line 67:
=== Levels ===
Software testing can be categorized into levels based on how much of the [[software system]] is the focus of a test.<ref name="Computer.org">{{Cite book |title=Guide to the Software Engineering Body of Knowledge |publisher=IEEE Computer Society |year=2014 |isbn=978-0-7695-5166-1 |editor-last=Bourque |editor-first=Pierre |series=3.0 |chapter=Chapter 5 |access-date=January 2, 2018 |editor-last2=Fairley |editor-first2=Richard E. |chapter-url=https://www.computer.org/web/swebok/v3}}</ref><ref name="BourqueSWEBOK14-4">{{Cite book |title=SWEBOK v3.0: Guide to the Software Engineering Body of Knowledge |publisher=IEEE |year=2014 |isbn=978-0-7695-5166-1 |editor-last=Bourque, P. |pages=4–1–4–17 |chapter=Chapter 4: Software Testing |access-date=July 13, 2018 |editor-last2=Fairley, R.D. |chapter-url=http://www4.ncsu.edu/~tjmenzie/cs510/pdf/SWEBOKv3.pdf |archive-date=June 19, 2018 |archive-url=https://web.archive.org/web/20180619003324/http://www4.ncsu.edu/~tjmenzie/cs510/pdf/SWEBOKv3.pdf |url-status=dead }}</ref><ref name="DooleySoftware11">{{Cite book |last=Dooley, J. |url=https://books.google.com/books?id=iOqP9_6w-18C&pg=PA193 |title=Software Development and Professional Practice |publisher=APress |year=2011 |isbn=978-1-4302-3801-0 |pages=193–4}}</ref><ref name="WiegersCreating13">{{Cite book |last=Wiegers, K. |url=https://books.google.com/books?id=uVsUAAAAQBAJ&pg=PA212 |title=Creating a Software Engineering Culture |publisher=Addison-Wesley |year=2013 |isbn=978-0-13-348929-3 |pages=211–2}}</ref>
==== Unit testing ====
Line 97:
Software testing can often be divided into white-box and black-box. These two approaches are used to describe the point of view that the tester takes when designing test cases. A hybrid approach called grey-box includes aspects of both boxes may also be applied to software testing methodology.<ref name="LimayeSoftware09">{{Cite book |last=Limaye, M.G. |url=https://books.google.com/books?id=zUm8My7SiakC&pg=PA108 |title=Software Testing |publisher=Tata McGraw-Hill Education |year=2009 |isbn=978-0-07-013990-9 |pages=108–11}}</ref><ref name="SalehSoftware09">{{Cite book |last=Saleh, K.A. |url=https://books.google.com/books?id=N69KPjBEWygC&pg=PA224 |title=Software Engineering |publisher=J. Ross Publishing |year=2009 |isbn=978-1-932159-94-3 |pages=224–41}}</ref>
==== White-box testing ====
{{Main|White-box testing}}
Line 130 ⟶ 131:
Specification-based testing aims to test the functionality of software according to the applicable requirements.<ref>{{Cite thesis |last=Laycock |first=Gilbert T. |title=The Theory and Practice of Specification Based Software Testing |degree=dissertation |publisher=Department of Computer Science, [[University of Sheffield]] |url=http://www.cs.le.ac.uk/people/glaycock/thesis.pdf |year=1993 |access-date=January 2, 2018}}</ref> This level of testing usually requires thorough [[test case]]s to be provided to the tester, who then can simply verify that for a given input, the output value (or behavior), either "is" or "is not" the same as the expected value specified in the test case. Test cases are built around specifications and requirements, i.e., what the application is supposed to do. It uses external descriptions of the software, including specifications, requirements, and designs to derive test cases. These tests can be [[functional testing|functional]] or [[non-functional testing|non-functional]], though usually functional. Specification-based testing may be necessary to assure correct functionality, but it is insufficient to guard against complex or high-risk situations.<ref>{{Cite journal |last=Bach |first=James |author-link=James Bach |date=June 1999 |title=Risk and Requirements-Based Testing |url=http://www.satisfice.com/articles/requirements_based_testing.pdf |journal=Computer |volume=32 |issue=6 |pages=113–114 |access-date=August 19, 2008}}</ref>
Black box testing can be used to any level of testing although usually not at the unit level.
'''Component interface testing'''
Line 245 ⟶ 246:
=== Accessibility testing ===
[[Accessibility]] testing is done to ensure that the software is accessible to persons with disabilities. Some of the common web accessibility tests are
* Ensuring that the color contrast between the font and the background color is appropriate
Line 337 ⟶ 338:
In an organization, testers may be in a separate team from the rest of the [[software development]] team or they may be integrated into one team. Software testing can also be performed by non-dedicated software testers.
In the 1980s, the term ''software tester'' started to be used to denote a separate profession.
Notable software testing roles and titles include:<ref>{{Cite journal |last1=Gelperin |first1=David |author-link=Dave Gelperin |last2=Hetzel |first2=Bill |author-link2=William C. Hetzel |date=June 1, 1988 |title=The growth of software testing |journal=Communications of the ACM |volume=31 |issue=6 |pages=687–695 |doi=10.1145/62959.62965 |s2cid=14731341|doi-access=free }}</ref> ''test manager'', ''test lead'', ''test analyst'', ''test designer'', ''tester'', ''automation developer'', and ''test administrator''.<ref>{{Cite book |last1=Gregory |first1=Janet |title=More Agile Testing |last2=Crispin |first2=Lisa |publisher=Addison-Wesley Professional |year=2014 |isbn=978-0-13-374956-4 |pages=23–39}}</ref>
Line 521 ⟶ 522:
{{Div col|colwidth=40em}}
* {{Annotated link|Data validation}}
* {{
* [[Database testing]], testing of databases
* {{
* {{Annotated link|Dynamic program analysis}}
* {{Annotated link|Formal verification}}
Line 547 ⟶ 548:
== External links ==
{{commons category}}
{{Wikiversity department}}
* [https://www.economist.com/technology-quarterly/2008/03/08/software-that-makes-software-better "Software that makes Software better" Economist.com]
| |||