Don’t Go over the Waterfall: Keep Agile Testing Agile
of 20
/20
-
Author
techwellpresentations -
Category
Technology
-
view
82 -
download
0
Embed Size (px)
description
All too often an agile iteration resembles a mini-waterfall cycle with developers coding for the duration of the iteration and then throwing code “over the wall” to the test team. This results in the all-too-familiar “test squeeze” with testers often testing code after the iteration has already finished. When testing occurs after an iteration’s end, the agile principle of potentially releasable is violated and negatively impacts the next iteration. To avoid these problems we must ensure that all testing is completed before the end of the iteration. But how can we achieve this? Aaron Barrett explains that the solution lies in the planning and processes that govern the agile team. Learn proven strategies that allow your test teams to move testing back inside the iteration and take back a plan to keep you from going over the waterfall.
Transcript of Don’t Go over the Waterfall: Keep Agile Testing Agile
W16 Concurrent Class
10/2/2013 3:00:00 PM
"Don’t Go over the Waterfall:
Keep Agile Testing Agile"
Presented by:
Aaron Barrett
Infusionsoft
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073
888-268-8770 ∙ 904-278-0524 ∙ [email protected] ∙ www.sqe.com
Aaron Barrett
Infusionsoft
Aaron Barrett is the director of quality assurance at Infusionsoft in Chandler, Arizona. But
Aaron’s first testing job was seventeen years ago at a small educational software company.
Since that time he has held testing and management roles in a variety of organizations in the
government, education, and business software verticals. A certified ScrumMaster, Aaron
currently oversees a test group that operates in an agile Scrum software development
environment.
9/20/2013
1
Keep Agile Testing Agile
Don’t Go Over the Waterfall:
• 17+ years in QA as both a practitioner and manager
• Managed large off-shore test teams
• Created test automation and perf test groups from scratch
• Established and grew QA team at Infusionsoft
• Certified Scrum Master
Aaron Barrett Director of QA at Infusionsoft
9/20/2013
2
Do your agile iterations look like this?
Or this?
9/20/2013
3
Or this?
There is a rhythm to Software Development – Things need to be done in a sequential order
Why does this happen?
9/20/2013
4
What a 2 week iteration looks like to a developer
What a 2 week iteration looks like to a tester
9/20/2013
5
Sure sign that your Agile iterations aren’t agile
Ideal Burndown Chart
9/20/2013
6
Always keep the end goal in mind – Every iteration should produce Potentially Releasable Software!
So what can we do about Agile iterations that aren’t agile?
As QA professionals, would we ever allow untested software to be shipped, or deployed to production? Why then would we allow an iteration to end without fully tested, potentially releasable code?
9/20/2013
7
Before a single line of code is written the entire Agile team needs to agree on a definition of done.
This is the most important thing that you can do to make Agile agile!
Be Grumpy!
9/20/2013
8
You will need 3 things before the iteration coding/testing can begin: 1. Completed designs 2. User stories 3. Some form of user story augmentation
Before the Iteration begins.
Get QA as far upstream as possible.
Designs are created
9/20/2013
9
EXAMPLE: US6027 - As a user I want to be able to see my appointments on the My Day page so that I can see how my day is looking
User stories are written
EXAMPLE: Acceptance Criteria: • Each appointment has a:
– appointment title – Time range (my time zone) – Location – Attendee (only one)
• I should see my appointments for today - but only three at a time should show (i.e. the appointments panel is fixed height). If there are more than three appointments that need to be displayed, a scrollbar will be present on mousover.
• As the day progresses, appointments should fall off the list anytime the page is refreshed. This is based on the end time of the appointment
• Appointments that display are limited to today and tomorrow. • Select states should work properly • Appointments display in the working panel above the tasks. • Appointments should live in their own container • "No current appointment" message should show if there are no appointments for
the user • The height of this container should remain consistent, even if there are not three
appointments displayed.
User stories are augmented
9/20/2013
10
Pictures are nice too
4 things need to happen before coding can begin: 1. Iteration Planning 2. Code Design 3. Test Cases created 4. Test Cases reviewed by Developer(s)
Before coding begins
9/20/2013
11
Stories are estimated and MUST INCLUDE QA’S TIME!
Iteration Planning
Not a QA function, but it sure makes QA’s lives easier
Developers do code design
9/20/2013
12
THIS IS NOT A WATERFALL EXERCISE! 15 to 3o minutes max
Example: 1. Look for the "Pick time" link 2. Click on the "Pick time" link 3. Observe the modal header 4. Observe the times on the left column 5. Open for a day with an existing all day appointment 6. Attempt to move or edit existing any appointment 7. Use the arrows in the header to change the day being viewed 8. Observe the header when toggling through days 9. Click the "Today" button 10. Add an appointment 11. Pull the bottom edge of the time block to make it larger or smaller 12. Click save in the modal 13. Click cancel on the modal 14. Change the day selected in the modal and save 15. Add an appointment to overlap an existing appointment (double book) 16. Add an appointment and drag to the All Day control at the to of the modal 17. Use special character when titling a new appointment 18. Use HTML/SQL in title of appointment 19. Use accented characters in an appointment title 20. Add an appointment with the title of 'null' 21. Create an all day appointment from within MyDay 22. Click the 'All Day' control
QA writes test cases
The goal of this is to arrive at shared purpose with a
clear understanding of what is supposed to be coded
Developers review Test Cases
9/20/2013
13
As code is completed 3 things need to happen: 1. Dev and QA pair test in the Dev’s sandbox 2. Code is committed to pre-production/staging 3. QA executes test case in pre-production/staging
As code is completed
Dev and QA sit down together and run through the test cases in the Developer’s sandbox environment
before code is committed.
Dev/QA Pair Testing
9/20/2013
14
DO NOT PROCEED UNTIL ALL TEST CASES PASS!
Code is committed to the codebase and can now be built/deployed to the pre-production/staging
environment
Code committed to codebase
9/20/2013
15
QA runs through the test cases, primarily looking for regression errors.
QA tests in pre-production/staging environment
DO NOT PROCEED UNTIL ALL TEST CASES PASS!
9/20/2013
16
Some form of a general regression should be run before the iteration ends
Before the iteration ends
DO NOT PROCEED UNTIL ALL TEST CASES PASS!
9/20/2013
17
Deploy the code to
Production…
or not
After the end of the iteration
• Keep end goal in mind – Potentially Releasable Software
• Before coding starts Agile team agrees on a definition of “done”
• QA time is included in story estimates
• Test Cases are reviewed by Dev
• Dev/QA pair test in sandbox environment before code is
committed
• QA tests again in pre-production environment
• QA performs a regression test in pre-production environment
• Iteration ends and code is ready to be released to Production
In Summary
9/20/2013
18
Questions?
