Developers have a tendency to overbuild their code. This is frequently due to not knowing exactly when they're done and not knowing how robust a feature needs to be. Acceptance test-driven development (ATDD) is a great way to avoid this practice because when the acceptance test passes, the developer knows they're done building that particular feature.
Acceptance test-driven development is a whole-delivery cycle method that allows the entire team to define system behavior in specific terms before coding begins. These conversations align the expectations of the testers, developers, and product owners, forcing any silly arguments to happen before someone has to create the code twice. Here are some great beginner exercises for teaching ATDD.
In the world of IT outsourcing, it is not uncommon for a company to have its applications and infrastructure developed or maintained by others. As vendors compete for this business, a common trial is testing the transition activity as a whole. How would you design acceptance criteria of a transition trial so that it is testable and clearly communicated?
In the movie RoboCop, the cyborg law enforcement officer advised people to “Stay out of trouble.” This article focuses on ways to stay out of trouble when building a software product by following the stages of software testing, using the 1987 movie’s titular character as an example. Let’s examine each testing stage and see if we can build a better RoboCop.
Brooke Bowie explains how "adaptive" software testing provides nimble, high-value software test solutions that bend and shift with the changing needs of the market or the environment. High-value testing does not mean that you need to perform all end-to-end testing or run the full suite of tests; this can potentially create a bottleneck and dampen the velocity. Adaptive tests are always targeted at the most relevant business and quality goals.
Vague or ambiguous requirements can cause loops in development processes. Creating requirements that include acceptance tests cuts down on the looping and increases the flow of working software to the customer.
Acceptance test-driven development (ATDD) means different things to different people based on their experiences—from "It's all about testing" to "It has nothing to do with testing,” and from "TDD, ATDD—it's all the same" to "TDD and ATDD are nothing alike." These nine landmarks will help you navigate ATDD no matter where you are coming from.
In this interview, principal consultant and Agile Artisans founder, Jared Richardson, explains how misunderstanding requirements can cause major issues within an organization. He covers why team members need to communicate, how big projects are often mishandled, and the value of agile.
StickyMinds technical editor Matthew Heusser is a consulting software tester and software process naturalist. In this interview, Matthew shares his thoughts on tester and programmer relationships, the impact of Acceptance Test Driven Development, and benefits of "lean coffee" gatherings.
Defining, understanding, and agreeing on the scope of work to be done is often an area of discomfort for product managers, business analysts, developers, and quality assurance experts alike. The origin of many items living in our defect tracking systems can be traced to the difficulties encountered while performing these initial requirements activities. Ken Pugh introduces behavior-driven development (BDD), also known as acceptance test-driven development (ATDD), and explains how it works in creating detailed requirements. He outlines the different roles that team members play in the process. BDD/ATDD has proven to dramatically increase productivity and reduce delays in development by decreasing re-work due to requirement misunderstandings.
While Information and Communication Technology (ICT) accessibility for a wider spectrum of users—including the blind—and their interfaces is being required by law across more jurisdictions, testing for it remains limited, naïve, and too late. The consequences of staying ignorant include...
The practice of software development requires a clear understanding of business needs. Misunderstanding requirements causes waste, slipped schedules, and mistrust. Developers implement their perceived interpretation of requirements; testers test against their perceptions. Disagreement can...
Centralization of testing services into a testing center of excellence (TCoE) for system testing is common in IT shops today. To make this transformation mature, the next logical step is to incorporate the user acceptance testing (UAT) function into the TCoE. This poses unique challenges...