Embed Size (px)
Citation preview
Acceptance Test Driven Development1.29.2015
● Common Agile QA Problems (5 mins)
● Acceptance Test Driven Development (ATDD) - A Solution (10 mins)
● Real World Results (5 mins)
● Tips for implementing ATDD (5 mins)
● Questions (5 mins)
Agenda
“Absorb what is useful,
discard what is useless
and add what is specifically your own.”
-Bruce Lee
Make It Your Own
● QA kept out of the loopo Automation last to be notified of functionality, putting the team behind
and restricting them to regression script writing
● QA does not complete their acceptance tests until after the sprint had started o Spike in effort from the QA team which does not allow them to focus
on testing
● Dev and QA out of synco Little understanding between dev and QA about Unit/Integration
testing by dev and System/ Acceptance testing by QA
● Lack of understanding or inability to qualify when QA is “Done” with testing.
Why QA Breaks Down in Agile
• Testing the Code– Test Driven Development (TDD)
• Develop with testing in mind• Provides quick feedback on code quality
• Testing the Product– Acceptance Test Driven Development (ATDD)
• Outlines specifically what a user should be able to do with the product
• Allows the test team to know when they are “done” • Drives communication between the business and
engineering teams
ATDD as a Solution
A Typical Sprint
Dev Code/Test Code/Test Code/Test Code/Test Code/Test
Day 1 Day 2 Day 3 Day 4 Day 5
FA Test Plan Test - Color Test - Color Test Test TestTest Test upload to Qtest
DEV
QA
Everyone Sprint Planning Arch Review Sprint Planning Internal Demo
Dev Code/Test Code/Test Code/Test Code/Test Code/Test
Day 6 Day 7 Day 8 Day 9 Day 10
FA Test Plan Test - Color Test - Color Test Test Test Test Test
DEV
FA
Everyone Sprint Planning Arch Review Sprint Planning Internal Demo
Dev Bugs/Refactor Bugs/Refactor Bugs/Refactor Bugs/Refactor Bugs/Refactor
Day 11 Day 12 Day 13 Day 14 Day 15
FA Test Plan Test - Color Test - Color Test Test - ProductionTest Test Test
DEV
FA
Everyone Sprint Planning Arch Review Sprint Planning Demo & Retrospective
The user story is the “What.” Allows the business to explain a business need while leaving development to choose the best technical approach
Example:
As a paying customer,I want to have the ability to update my billing information
on my recurring subscription,So that I can keep my subscription current if my
information changes.
User Stories - Sprint Planning
Acceptance Criteria
Acceptance criteria are how we define “done.” They’re measures for how a system should perform. They:
• Define the system behavior.• Ensure features work as expected.• Provide the team a better gauge of the
amount of work needed to complete a story.• Guide Development and QA testing.
Acceptance Criteria Example
Examples based on user story:
• There should be a navigation element the user can select from to update their billing information
• The user should have the ability to update either their billing address or their payment methods for the recurring payment
• A notification should be shown to the user stating that changes will not go into effect until next billing cycle
Acceptance Tests
Verify the work: Acceptance tests evaluate the acceptance criteria using the “Given-When-Then” format.
• Given: The given clause sets the stage for the initial scenario being tested or the stage the user is at prior to testing
• When: The when clause describes the action the user performs on the system
• Then: The then clause describes the system’s reaction to the action performed in the when clause
Acceptance Test Example
Example based on Acceptance Criteria:
Given the customer has navigated to the billing page
When the customer clicks on “Update Billing Information” and clicks “Change Address,”
Then the customer is presented with a form to enter a new address.
How does the process work with our tools?
User Story Acceptance Criteria Testing Tasks
Test Case Test Runs
JIRA
qTest When the Test Run passes, complete the testing task
DONE!
● QA have become the Subject Matter Experts (SME’s) for the product
● Acceptance test cases get created during sprint planning which frees up time in sprint to test
● Team can focus on more complex test scenarios including system testing and leading UAT sessions with the business
● QA and Dev can discuss the split of testing to limit overlap between Unit, Integration and Acceptance Testing
Improvements for Manual QA
Improvements for Automation
• BetterCloud writes automated cases in Groovy with the Spock framework:
– Spock - higher level language, like a manual acceptance test
– Groovy - object oriented programming language, drives desired activity in the application
• Reduced the amount of time between functionality being delivered and automation coverage being created
Groovy and Spock Example
● Dispel rumors about automation:o Automation does not have to be regulated to the tools being usedo Automation does not have to be the final step in the
development/testing process
● Automation is not ALWAYS about automation test coverageo Created a chrome extension to accelerate manual “checking” effort
Automation team assisted in creating a Chrome extension to accelerate the process
● Shaved 75% in level of effort by testing team for this project
Achieve Outside-the-Box Automation
Chrome Tool
● Include the test automation team early and often in sprint planning
● Do not think “inside the tool” with test automation. Learn about other efficiencies that can be gained, like creating scripts in powershell or a chrome extension tool.
● Focus on communication and collaboration. Those are the two key points to a successful Agile team
● Both Manual and automated testers working together are key
Tips
