Acceptance test-driven development: Difference between revisions

Content deleted Content added
Monkbot (talk | contribs)
m Task 18 (cosmetic): eval 8 templates: hyphenate params (5×);
Adding short description: "Methodology in software development"
 
(7 intermediate revisions by 7 users not shown)
Line 1:
{{Short description|Methodology in software development}}
{{Software development process}}
 
Line 12 ⟶ 13:
=== 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|last1=Weinberg|first1=Gerald|last2=Gause|first2=Donald|author-link=Gerald_WeinbergGerald Weinberg|title=Exploring Requirements: Quality Before Design|publisher=Dorset House|year=1989|isbn=0-932633-13-7|url-access=registration|url=https://archive.org/details/exploringrequire00gaus}}</ref> A requirement that lacks a test may not be implemented properly. A test that does not refer to a requirement is an unneeded test. An acceptance test that is developed after implementation begins represents a new requirement.<ref>Martin, Robert C., and Grigori Melnik.{{cite web | url = http://www.gmelnik.com/papers/IEEE_Software_Moebius_GMelnik_RMartin.pdf | title = Tests and Requirements, Requirements and Tests: A Möbius Strip | access-date = 2013-04-15}}</ref>
 
=== Testing strategy ===
 
Acceptance tests are a part of an overall testing strategy. They are the customer/user oriented tests that demonstrate the business intent of a system. ComponentDepending testson areyour technicaltest acceptancestrategy, testsyou developedmay byuse anthem architectin thatcombination specifywith theother behaviortest of largetypes, modulese.g. lower level 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 testing includesincluding usability testing,<ref>Meszaros, Gerard, and Janice Aston. (2006) "Adding Usability Testing to an Agile Project." Agile Conference</ref> exploratory testing,<ref>{{cite web | title = Exploratory Testing Explained | date = 23 March 2019 | url = http://www.satisfice.com/articles/et-article.pdf }}</ref> and property testing (scaling and security).<ref>Meszaros, Gerard.(2007) ''xUnit Test Patterns: Refactoring Test Code''. Addison-Wesley.</ref>
 
== Acceptance criteria and tests ==
Line 71 ⟶ 72:
! Users
|-
| Name
|-
| Sam
|}