![Agile re-defines acceptance testing as a “formal description of the behavior of a software product[1].”](https://tcagley.files.wordpress.com/2015/09/20056195639_9d4a813de9_k.jpg?w=382&h=478)
Agile re-defines acceptance testing as a “formal description of the behavior of a software product[1].”
Agile begins the acceptance testing process as requirements are being discovered. Acceptance tests are developed as part of the of the requirements life cycle in an Agile project because acceptance test cases are a form of requirements in their own right. The acceptance tests are part of the overall requirements, adding depth and granularity to the brevity of the classic user story format (persona, goal, benefit). Just like user stories, there is often a hierarchy of granularity from an epic to a user story. The acceptance tests that describe a feature or epic need to be decomposed in lock step with the decomposition of features and epics into user stories. Institutionalizing the process of generating acceptance tests at the feature and epic level and then breaking the stories and acceptance test cases down as part of grooming is a mechanism to synchronize scaled projects (we will dive into greater detail on this topic in a later entry).
As stories are accepted into sprints and development begins, acceptance test cases become a form of executable specifications. Because the acceptance test describes what the user wants the system to do, then the functionality of the code can be compared to the expected outcome of the acceptance test case to guide the developer.
When development of user stories is done the acceptance test cases provide a final feedback step to prove completion. The output of acceptance testing is a reflection of functional testing that can be replicated as part of the demo process. Typically, acceptance test cases are written by users (often Product Owners or subject matter experts) and reflect what the system is supposed to do for the business. Ultimately, it provides proof to the user community that the team (or teams) are delivering what is expected.
As one sprint follows another, the acceptance test cases from earlier sprints are often recast as functional regression tests cases in later sprints.
Agile user acceptance testing is a direct reflection of functional specifications that guide coding, provide basis for demos and finally, ensure that later changes don’t break functions that were develop and accepted in earlier sprints. UAT in an Agile project is more rigorous and timely than the classic end of project UAT found in waterfall projects.
[1] http://guide.agilealliance.org/guide/acceptance.html, September 2015
September 3, 2015 at 11:55 pm
[…] in AUAT. AUAT is not a single event, but rather is integrated directly into every step of the product life cycle. Acceptance test cases are a significant part of requirements. Techniques such as Acceptance Test […]
September 6, 2015 at 9:44 am
As an addition: Its pretty easy to take a subset of tests and let them run against a live system. This turns acceptance testing into monitoring. Especially when you have some kind of generic storage for logs. Plus: I love this for an extra post deployment check.
My cucumber.js tests support a special tag fir stuff I want to test live and a environment variable to configure the server base url.
Still issues with stability eist and there are solutions out there. You might find yourself extending your or use your monitoring dump to decide when to raise an error.
The idea is somewhat stolen from:
http://www.xpdays.de/2014/sessions/002-extreme-continuous-delivery-at-unruly.html