Editing Test case (section)

== 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>