Acceptance software testing
Ted Neward’s 2006 essay “The Vietnam of Computer Science” famously compares Object/Relational mapping to the Vietnam War: “The United States began a military project with simple yet unclear and conflicting goals, and quickly became enmeshed in a quagmire that … brought down two governments”. The analogy can equally apply to Automated Acceptance Testing: early successes lead to committing to use Cucumber Tests for all stories; more and more resources get spent covering difficult cases and maintaining fragile tests; before you know it your project is bogged down, and you are scrambling for the last helicopter off the embassy roof. This video present on the goals of acceptance testing, when and how to use them and, as importantly, when not to use them.
This blog post covers the required implementation to get started with writing Acceptance Tests in a real Java project with JBehave.
In this blog post, Alister Scott explains why it might be better to write acceptance tests in a different language than your code.
This blog post presents the summary of two workshops that aimed at collaboratively creating the ATDD community of practice pattern language.
An interesting posts about how a tester collaborate with the product owner in an agile team to define the acceptance tests.
Many of the most common problems people have with implementing BDD or agile acceptance testing come from a misalignment of conceptual models. By changing our view at the specifications/tests we can make most of those issues go away instantly. This post explains the principle of symmetric change: one small change in a business model should require one small change to executable specifications.
One of the biggest benefits from acceptance testing for me was that the teams finally get a source of information on what goes on in the system as reliable as the code itself. Without acceptance tests, code is the only thing you can really trust and any other documentation gets outdated very quickly. Acceptance tests stay relevant throughout the project because they are automated, and automated tests are kept up to date in order for them to pass. Automation, and consequently a tool, are necessary to get this benefit.
