Content deleted Content added
m →Overview: repair cs1 templates with unsupported parameters; (1× access-date) |
Citation bot (talk | contribs) Alter: title, template type. Add: isbn, pages, volume, year, series, doi, chapter, author pars. 1-2. Removed URL that duplicated unique identifier. Removed parameters. Formatted dashes. Some additions/deletions were actually parameter name changes. | You can use this bot yourself. Report bugs here. | Suggested by AManWithNoPlan | All pages linked from cached copy of User:AManWithNoPlan/sandbox2 | via #UCB_webform_linked |
||
Line 8:
== Overview ==
Acceptance tests are from the user's point of view – the external view of the system.<ref name="Pugh11" /> They examine externally visible effects, such as specifying the correct output of a system given a particular input. Acceptance tests can verify how the state of something changes, such as an order that goes from "paid" to "shipped". They also can check the interactions with interfaces of other systems, such as shared databases or web services. In general, they are implementation independent, although automation of them may not be.<ref>Melnik, Grigori, and Frank Maurer. {{cite
=== Creation ===
Acceptance tests are created when the requirements are analyzed and prior to coding.<ref name="Pugh11" /> They can be developed collaboratively by requirement requester (product owner, business analyst, customer representative, etc.), developer, and tester. Developers implement the system using the acceptance tests. Failing tests provide quick feedback that the requirements are not being met. The tests are specified in business ___domain terms. The terms then form a ubiquitous language that is shared between the customers, developers, and testers.<ref>Evans, Eric. (2003) ''Domain-Driven Design: Tackling Complexity in the Heart of Software''. Addison-Wesley Professional.</ref> Tests and requirements are interrelated.<ref>{{cite book|
=== Testing strategy ===
| |||