The document outlines the process of Acceptance Test Driven Development (ATDD), emphasizing collaboration among Business Analysts (BAs), Developers, and Quality Assurance (QA) teams to define acceptance criteria and test scenarios before development. It highlights the advantages of ATDD, such as faster feedback cycles, reduced automation backlog, and improved team collaboration, leading to fewer functional bugs. The document also includes examples of executable test scenarios for login functionality, illustrating the practical application of ATDD.

2. Acceptance Test Driven Development (ATDD) in practice Ketan Soni

3. Typical flow in industry BAs specify requirements Devs develop functionality QAs identify test scenarios BAs verifies functionality Business sign off QAs -Testing + automate scenarios

4. From “Functional Test” perspective what all problems / concerns do you guys see in this flow? From Devs perspective Late Feedback Functional test does not help From QA s perspective Automation always lags behind QA sign off without automation Lesser time for exploratory testing From Team perspective Collaboration within Team (Dev/QA/BA)

5. How to overcome problems? “ Begin with the end in mind.” — Stephen R. Covey One way that worked for us: Acceptance Test Driven Development (ATDD) is a practice in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins.

6. BA Login functionality… As a user When I enter login credentials Then I should get authenticated

7. QA Executable test scenarios in human readable format… Scenario 1 : Verify valid login credentials… Given I am on login page When I login as username “test” and password “testing” Then I should get authenticated Scenario 2 : Verify logout functionality… Given I am a logged in user When I click on “logout” link Then I should be logged out BA Verify

8. Dev Application code to make the above statements pass… //Create login page // Implement the back-end for login functionality… Scenario 1 : Verify login functionality… Given I am on login page When I login as username “test” and password “testing” Then I should get authenticated… Test Scenario … Scenario 1 : Verify login functionality… Given I am on login page When I login as username “test” and password “testing” Then I should get authenticated 1) Developers run this test scenario and expect it to fail 2) To make the above executable statements pass, developer write the application and implement the login functionality… 3) Developers run the test scenario mentioned in step 1 and expect it to pass…

9. QA Scenario : Verify login and logout functionality… Given I am on login page When I login as username “test” and password “testing” Then I should get authenticated When I click on “logout” link Then I should logout + Consolidation of test scenarios… MANUAL TESTING

10. Typical ATDD flow… 1 QAs + BAs write scenarios 1 Developers implement scenarios 1 QAs - Manual Testing and consolidation of scenarios

11. Faster feedback cycle No Automation Backlog. QA’s get more time to do exploratory testing. Developers think from different angle while coding. Very less functional bugs No separate Test case repository Greater collaboration within Team Benefits of ATDD…

12. Questions?