How Acceptance Test-Driven Development (ATDD) can Impact Your Organization

AUGUST 5, 2016 // By John Peters

In Wiki, on this subject we read in the very first line...

"Acceptance test–driven development (ATDD) is a development methodology based on communication between the business customers, the developers, and the testers."

This statement is very simple and yet very profound. Later we read...

"ATDD encompasses acceptance testing, but highlights writing acceptance tests"

and later...

"Acceptance tests are created when the requirements are analyzed prior to coding."

Implementation of ATDD within TFS

Assume first that the project team must include the Customer, Product Owner, Business Systems Analysts, Project Managers, the Programming Team and the QA Team. Also, the business is committed to the general rules listed above and that TFS is the primary ALM (Application Life-cycle Management) tool.

Detailed Descriptions are a requirement

Each User Story or Product Back Log item must have a very detailed description. It should follow the "As a <user type> I want this <function> because I need to <do something>"

Acceptance Criteria is a requirement

Most users of TFS already use either the User Story or Product Back Log Item (PBI) to write the description of what needs to be done; but, not everyone enforces the need to log Acceptance Criteria. This would be a must on each and every User Story/PBI.  

All User Stories or PBIs must have attached Test Cases

The most logical method would be to attach manual test cases based on the acceptance criteria and descriptions of the User Story/PBI. They can start out as placeholders (test stubs) but must be mostly complete prior to starting the coding phase. 

Meeting to approve the current iteration content

All of the User Stories/PBIs, Acceptance criteria, and Tests are reviewed and approved by key stakeholders (Customer, Product Owner, Programming Team, BSA Team, and the QA Team).  It's critical that everyone approves the "content" for the upcoming "Coding Iteration".

Kick Off Meeting to Start Coding Iteration 

The team is informed at the start of coding iteration of all the rules and agree to follow them. Heavy focus is on the Acceptance Criteria. Developers agree to maintain and write new unit tests where needed using a Red Light, Green Light approach. All tests fail at first and code check in depends on the Test Case(s) passing. 

QA Team 

The QA team is able to embed with development and run any manual tests attached to the user story once a deliverable is there. Immediate feedback is given to the development team first. Either in a report or a bug. The QA Team then creates new Manual tests as the iteration progresses; where needed, adding to the already approved tests.

TFS allows Test Case entry through the web client, creation of Test Suites, and Test Run Results are immediately visible to all with a need to know. 

Risk Assessment 

Risk Assessment should always be objective, and confirmed by reports on how many tests have passed, failed, bug arrival rates etc. Once again TFS does this automatically. 

lightbulb with green background

Benefits of this Approach

  • The Test Plan is implicit in the attached Test Cases which cover the Acceptance Criteria
  • The entire team is now on the same page with respect to building quality into the product first.
  • Nobody takes a direct hit for production defects, because the entire team approved the quality aspects first.
  • Risks are known because the test coverage is increased and it's been pre-approved.   Reports are there 24/7 for each iteration on the TFS work board.
  • Your customers are happier because things just work.

If you'd like to learn more about ATDD and how it can impact your organization, you can contact Magenic by emailing us or calling us at 877-277-1044.

Categories // Quality Assurance & Testing
Tags // TFS, ALM, Acceptance Testing

Get Started

Contact Us