• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
VodQA3_ATDD_KetanSoni
 

VodQA3_ATDD_KetanSoni

on

  • 607 views

This was a full length talk presented by Ketan Soni in vodQA-3 : A QA Meet held in ThoughtWorks, Pune.

This was a full length talk presented by Ketan Soni in vodQA-3 : A QA Meet held in ThoughtWorks, Pune.

Statistics

Views

Total Views
607
Views on SlideShare
607
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    VodQA3_ATDD_KetanSoni VodQA3_ATDD_KetanSoni Presentation Transcript

    •  
    • Acceptance Test Driven Development (ATDD) in practice
      • Ketan Soni
    • Typical flow in industry BAs specify requirements Devs develop functionality QAs identify test scenarios BAs verifies functionality Business sign off QAs -Testing + automate scenarios
    • 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)
    • 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.
      • BA
      Login functionality… As a user When I enter login credentials Then I should get authenticated
      • 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
      • 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…
      • 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
    • Typical ATDD flow… 1 QAs + BAs write scenarios 1 Developers implement scenarios 1 QAs - Manual Testing and consolidation of scenarios
      • 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…
    • Questions?