a is for...

Acceptance Test

Also: Functional test, customer test

Pass/fail tests used to define whether or not a feature is functioning correctly, usually developed in parallel to the defining of the feature. These tests may be written in plain English by the customer or product owner (“The user clicks , the session is reset, and the user is redirected to the homepage”).

Ideally, an acceptance test is subsequently automated by the developer so that it can easily run on all iterations of the software, ensuring that the accepted feature has not been broken by newer development. The use of acceptance tests in subsequent iterations is also known as regression testing. Acceptance testing is a key feature of test-driven development (TDD).

In scrum: scrum does not specify testing methods, and testing is not a part of the scrum framework. This said, most scrum teams test, and within the scrum framework the product owner would be the appropriate person to define acceptance tests.

Background Of The Term

The concept of acceptance testing exists in engineering disciplines other than software development and is usually referred to as black-box testing.

Although acceptance testing is common across many agile disciplines, the term derives from Extreme Programming. According to C2.com, acceptance tests were first referred to as functional tests, because they test whether or not a feature works. Kent Beck, a primary mover behind TDD, proposed the change in terminology in April 2000.

Further Learning

Acceptance Testing – Agile Alliance glossary
Acceptance testing – Wikipedia entry

Posted in a | 2 Comments


An umbrella term for iterative, incremental software development methodologies. Agile approaches include Extreme Programming (XP), Scrum, Kanban, and Lean.

Agile methodologies arose in response to traditional, phase-driven “waterfall” development methods. Those emphasize top-down project management; “big design up front”; silos for architecture and design, coding, and testing; and extensive documentation. Agile methodologies share an emphasis on small teams delivering small increments of working software with great frequency while working in close collaboration with the customer and adapting to changing requirements.

Although the agile mindset originated with software, it has since been used for non-software projects such as in manufacturing, support, and marketing. For example, see the discussion at Can You Use Agile Project Management for Non-Software Projects

Background Of The Term

The term “agile” was first used by a group of software pundits who gathered at a ski lodge in Snowbird, Utah for the express purpose of naming and defining the greater movement in which they deemed themselves to all be participants. The original invitation to Snowbird went out to those interested in “lightweight” development frameworks. The attendees agreed that they didn’t like the negative connotations of “lightweight”, instead adopting the term “agile.”

Out of that meeting came the Agile Manifesto.

Further Learning

History: The Agile Manifesto – a little historical background on the manifesto and reflection on agility as recounted by Jim Highsmith, one of the signatories.

What Is Agile Product Management: Guide To Processes & Roles – blog post by Michael Luchen

What is Agile? – blog post from Atlassian

Posted in a | 4 Comments