Content deleted Content added
No edit summary |
m General formatting by script |
||
Line 1:
{{Software development process}}
'''Acceptance test–driven development''' (
</ref> and story test–driven development (SDD).<ref>{{cite web| url = http://industriallogic.com/papers/storytest.pdf | title = Story Test-Driven Development | accessdate = 2013-04-15}}</ref>
ATDD is closely related to [[test-driven development]] (TDD).<ref>Beck, Kent. Test Driven Development: By Example. Addison-Wesley Professional, 2002.</ref> It differs by the emphasis on developer-tester-business customer collaboration. ATDD encompasses [[acceptance testing]], but highlights writing acceptance tests before developers begin coding.
== 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
=== Creation ===▼
▲===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|last=Weinberg|first=Gerald|last2=Gause|first2=Donald|authorlink=Gerald_Weinberg|title=Exploring Requirements: Quality Before Design|publisher=Dorset House|year=1989|isbn= 0-932633-13-7}}</ref>
=== Testing Strategy ===▼
▲===Testing Strategy===
Acceptance tests are a part of an overall testing strategy. They are the customer tests that demonstrate the business intent of a system. Component tests are technical acceptance tests developed by an architect that specify the behavior of large modules. Unit tests are created by the developer to drive easy-to-maintain code.<ref>[Test-driven_development]</ref> They are often derived from acceptance tests and unit tests. Cross-functional test include usability,<ref>Meszaros, Gerard, and Janice Aston. (2006) "Adding Usability Testing to an Agile Project."Agile Conference</ref> exploratory,<ref>{{cite web | title = Exploratory Testing Explained | url = http://www.satisfice.com/articles/et-article.pdf }}</ref> and property (scaling and security).<ref>Meszaros, Gerard.(2007) ''xUnit Test Patterns: Refactoring Test Code''. Addison-Wesley.</ref>
== Acceptance criteria and tests ==
Acceptance criteria are a description of what would be checked by a test. Given a requirement such as “As a user, I want to check out a book from the library”, an acceptance criterion might be “Verify the book is marked as checked out." An acceptance test for this requirement gives the details so that the test can be run with the same effect each time.
=== Test format ===
Acceptance tests usually follow this form:<ref name="Pugh11" />
'''Given (setup)'''
: A specified state of a system
'''When (trigger)'''
: An action or event occurs
'''Then (verification)''' ▼
:The state of the system has changed or an output has been produced▼
▲: The state of the system has changed or an output has been produced
For the example requirement, the steps could be listed as:
'''Given:'''
: Book that has not been checked out
: User who is registered on the system
'''When:'''
:User checks out a book ▼
'''Then:''' ▼
:Book is marked as checked out▼
===Complete test===▼
▲: Book is marked as checked out
▲=== Complete test ===
The previous steps do not include any specific example data, so that is added to complete the test:
'''Given:'''
: Book that has not been checked out
{| class="wikitable"
|-
! Books
|-
| Title || Checked out
Line 53 ⟶ 71:
|}
: User who is registered on the system
{| class="wikitable"
|-
! Users
|-
| Name
|-
| Sam
Line 64 ⟶ 83:
'''When:'''
: User checks out a book
{| class="wikitable"
|-
! Checkout action
|-
| User || Sam || Checks out
|}
'''Then:'''
: Book is marked as checked out
{| class="wikitable"
|-
Line 80 ⟶ 103:
| Title || Checked out || User
|-
| Great book || Yes ||
|}
=== Test examination ===
Examination of the test with specific data usually leads to many questions. For the sample, these might be:
* What if the book is already checked out?
* What if the book does not exist?
* What if the user is not registered on the system?
* Is there a date that the book is due to be checked-in?
* How many books can a user check out?
These questions help illuminate missing or ambiguous requirements. Additional details such as a due-date can be added to the expected result. Other acceptance tests can check that conditions such as attempting to check out a book that is already checked out produces the expected error.
=== Another test example ===
Suppose the business customer wanted a business rule that a user could only check out one book at a time. The following test would demonstrate that:
Line 99 ⟶ 126:
'''Given:'''
: Book that has been checked out
{| class="wikitable"
|-
! Books
|-
| Title || Checked out || User
Line 110 ⟶ 139:
| Another great book || No
|}
{| class="wikitable"
|-
! Users
|-
| Name
|-
| Sam
Line 120 ⟶ 150:
'''When:'''
: User checks out another book
{| class="wikitable"
|-
! Checkout action
|-
| User || Sam || Checks out || Another great book
|}
'''Then:'''
: Error occurs
{| class="wikitable"
|-
Line 139 ⟶ 173:
|}
=== Project acceptance tests ===
In addition to acceptance tests for requirements, acceptance tests can be used on a project as a whole.<ref name="Pugh11" /> For example, if this requirement was part of a library book checkout project, there could be acceptance tests for the whole project. These are often termed [[SMART criteria|SMART objectives]]. An example test is "When the new library system is in production, the users will be able to check books in and out three times as fast as they do today".
== See also ==
* [[
* [[
* [[Robot Framework]]
== References ==
{{Reflist}}
== External links ==
* [http://acceptancetestdrivendevelopment.com Example of automation frameworks]
{{DEFAULTSORT:Acceptance test-driven development}}
[[Category:Software development philosophies]]
[[Category:Software testing]]
| |||