Editing Test case (section)

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