Editing Test case


{{Short description|Specification of a software test, its objective and its procedure}}
{{about|the term in software engineering|the legal term|Test case (law)|other uses|Test case (disambiguation)}}

In [[software engineering]], a '''test case''' is a specification of the inputs, execution conditions, testing procedure, and expected results that define a single test to be executed to achieve a particular [[software testing]] objective, such as to exercise a particular program path or to verify compliance with a specific requirement.<ref>{{Cite book|date=2010-12-01|publisher= Iso/Iec/IEEE 24765:2010(E)|pages=1–418|doi=10.1109/IEEESTD.2010.5733835|isbn=978-0-7381-6205-8 |title=Systems and software engineering -- Vocabulary }}</ref> Test cases underlie testing that is methodical rather than haphazard. A [[Test suite|battery of test cases]] can be built to produce the desired coverage of the software being tested. Formally defined test cases allow the same tests to be run repeatedly against successive versions of the software, allowing for effective and consistent [[regression testing]].<ref>{{Cite journal|last=Kaner|first=Cem|date=May 2003|title=What Is a Good Test Case?|url=http://www.kaner.com/pdfs/GoodTest.pdf|journal=STAR East|pages=2}}</ref>

== Formal test cases ==

In order to fully test that all the requirements of an application are met, there must be at least two test cases for each requirement: one positive test and one negative test.<ref>{{Cite web|url=https://www.stickyminds.com/article/writing-test-rules-verify-stakeholder-requirements|title=Writing Test Rules to Verify Stakeholder Requirements|website=StickyMinds}}</ref> If a requirement has sub-requirements, each sub-requirement must have at least two test cases. Keeping track of the link between the requirement and the test is frequently done using a [[traceability matrix]]. Written test cases should include a description of the functionality to be tested, and the preparation required to ensure that the test can be conducted.

A formal written test case is characterized by a known input and by an expected output, which is worked out before the test is executed.<ref>{{cite book |last=Beizer |first=Boris |date=May 22, 1995 |title=Black Box Testing |url=https://archive.org/details/blackboxtestingt00beiz_0 |url-access=registration |location=New York |publisher=Wiley |page=[https://archive.org/details/blackboxtestingt00beiz_0/page/3 3] |isbn= 9780471120940}}</ref> The known input should test a [[precondition]] and the expected output should test a [[postcondition]].

== Informal test cases ==

For applications or systems without formal requirements, test cases can be written based on the accepted normal operation of programs of a similar class. In some schools of testing, test cases are not written at all but the activities and results are reported after the tests have been run.

In [[scenario testing]], hypothetical stories are used to help the tester think through a complex problem or system. These scenarios are usually not written down in any detail. They can be as simple as a diagram for a testing environment or they could be a description written in prose. The ideal scenario test is a story that is motivating, credible, complex, and easy to evaluate. They are usually different from test cases in that test cases are single steps while scenarios cover a number of steps of the key.<ref name="Kaner-Intro">{{cite web | title = An Introduction to Scenario Testing | url = http://www.kaner.com/pdfs/ScenarioIntroVer4.pdf | access-date = 2009-05-07 | publisher = Cem Kaner }}</ref><ref name="Crispin-Agile">{{cite book |last= Crispin |first= Lisa |author2=Gregory, Janet  |title= Agile Testing: A Practical Guide for Testers and Agile Teams |url= https://archive.org/details/agiletestingprac00cris |url-access= limited |publisher= [[Addison-Wesley]] |year= 2009 |isbn= 978-81-317-3068-3 |pages=[https://archive.org/details/agiletestingprac00cris/page/n231 192]–5}}</ref>

== Typical written test case format ==

A test case usually contains a single step or a sequence of steps to test the correct behavior/functionality and features of an application. An expected result or expected outcome is usually given.

Additional information that may be included:<ref name="Liu">{{cite book |last=Liu |first=Juan |title=2014 International Conference on Computational Science and Computational Intelligence |chapter=Equilibrium of Decision-Making Process in Financial Market |year=2014 |chapter-url=https://books.google.com/books?id=xK0tAwAAQBAJ&pg=PA116 |pages=113–121 |access-date=2019-10-22|isbn=9781605951676 |doi=10.1109/CSCI.2014.104 |s2cid=15204091 }}</ref>
*'''Test case ID''' - A unique identifier for the test case.
*'''Description/summary''' - The test case objective.
*'''Test steps''' - The exact steps to perform.
*'''Expected result''' - The expected outcome and how to determine whether it has been realized.
*'''Actual result'''
*'''Pre-requisites''' - Conditions that must exist or preparation required before test execution. 
*'''Test category'''
*'''Author''' - name of the tester.
*'''Automation''' - whether this test case is automated or not and, if so, how.
*'''Pass/fail''' 
*'''Remarks'''

Larger test cases may also contain prerequisite states or steps, and descriptions.<ref name="Liu" />

A written test case should also contain a place for the actual result.

These steps can be stored in a word processor document, spreadsheet, database or other common repository.

In a database system, you may also be able to see past test results and who generated the results and the system configuration used to generate those results. These past results would usually be stored in a separate table.

[[Test suite]]s often also contain<ref name="tcs">{{cite book |last1=Kaner |first1=Cem |last2=Falk |first2=Jack |last3=Nguyen |first3=Hung Q. |year=1993 |title=Testing Computer Software |url=https://archive.org/details/testingcomputers00kanerich |url-access=registration |edition=2nd |location=Boston |publisher=Thomson Computer Press |page=[https://archive.org/details/testingcomputers00kanerich/page/123 123–4] |isbn=1-85032-847-1}}</ref>
* Test summary
* Configuration

Besides a description of the functionality to be tested, and the preparation required to ensure that the test can be conducted, the most time-consuming part in the test case is creating the tests and modifying them when the system changes.

Under special circumstances, there could be a need to run the test, produce results, and then a team of experts would evaluate if the results can be considered as a pass. This happens often on new products' performance number determination. The first test is taken as the base line for subsequent test and product release cycles.

[[Acceptance test]]s, which use a variation of a written test case, are commonly performed by a group of [[end-user]]s or clients of the system to ensure the developed system meets the requirements specified or the contract.<ref>{{cite book |first1=Brian |last1=Hambling |first2=Pauline |last2=van Goethem |title= User Acceptance Testing: A Step-by-step Guide |year= 2013|publisher= BCS Learning & Development Limited|isbn= 9781780171678}}</ref><ref>{{cite book| last=Black | first=Rex | date=August 2009 | title= Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing | url=https://archive.org/details/managingtestingp00rexb | url-access=registration | publisher=Hoboken, NJ: Wiley | isbn=978-0-470-40415-7}}</ref> User acceptance tests are differentiated by the inclusion of [[happy path]] or positive test cases to the almost complete exclusion of negative test cases.<ref>{{cite book|last= Cimperman|first= Rob|title= UAT Defined: A Guide to Practical User Acceptance Testing|year= 2006|publisher= Pearson Education|isbn= 9780132702621|pages=Chapter 2}}</ref>

== See also ==

* [[Classification Tree Method]]

== References ==
{{reflist}}

== External links ==
*[http://www.stickyminds.com/s.asp?F=S15689_ART_2 Software Test Case Engineering] By Ajay Bhagwat
{{Software engineering}}

[[Category:Software testing|Case]]