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.

1. 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 ∙ sqeinfo@sqe.com ∙ www.sqe.com

2. 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.

3. 9/20/2013
Don’t Go Over the Waterfall:
Keep Agile Testing Agile
Aaron Barrett
Director of QA at Infusionsoft
• 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
1

4. 9/20/2013
Do your agile iterations look like this?
Or this?
2

5. 9/20/2013
Or this?
Why does this happen?
There is a rhythm to
Software Development –
Things need to be done in
a sequential order
3

6. 9/20/2013
What a 2 week iteration looks like to a
developer
What a 2 week iteration looks like to a
tester
4

7. 9/20/2013
Sure sign that your Agile iterations
aren’t agile
Ideal Burndown Chart
5

8. 9/20/2013
So what can we do about Agile
iterations that aren’t agile?
Always keep the end goal in mind – Every iteration
should produce Potentially Releasable Software!
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?
6

9. 9/20/2013
This is the most important thing that
you can do to make Agile agile!
Before a single line of
code is written the entire
Agile team needs to agree
on a definition of done.
Be Grumpy!
7

10. 9/20/2013
Before the Iteration begins.
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
Designs are created
Get QA as far upstream as possible.
8

11. 9/20/2013
User stories are written
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 augmented
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.
9

12. 9/20/2013
Pictures are nice too
Before coding begins
4 things need to happen before coding can begin:
1.
2.
3.
4.
Iteration Planning
Code Design
Test Cases created
Test Cases reviewed by Developer(s)
10

13. 9/20/2013
Iteration Planning
Stories are estimated and MUST INCLUDE QA’S TIME!
Developers do code design
Not a QA function, but it sure makes QA’s lives easier
11

14. 9/20/2013
QA writes test cases
Example:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
THIS IS NOT A WATERFALL EXERCISE!
15 to 3o minutes max
Look for the "Pick time" link
Click on the "Pick time" link
Observe the modal header
Observe the times on the left column
Open for a day with an existing all day appointment
Attempt to move or edit existing any appointment
Use the arrows in the header to change the day being viewed
Observe the header when toggling through days
Click the "Today" button
Add an appointment
Pull the bottom edge of the time block to make it larger or smaller
Click save in the modal
Click cancel on the modal
Change the day selected in the modal and save
Add an appointment to overlap an existing appointment (double book)
Add an appointment and drag to the All Day control at the to of the modal
Use special character when titling a new appointment
Use HTML/SQL in title of appointment
Use accented characters in an appointment title
Add an appointment with the title of 'null'
Create an all day appointment from within MyDay
Click the 'All Day' control
Developers review Test Cases
The goal of this is to arrive at shared purpose with a
clear understanding of what is supposed to be coded
12

15. 9/20/2013
As code is completed
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
Dev/QA Pair Testing
Dev and QA sit down together and run through the
test cases in the Developer’s sandbox environment
before code is committed.
13

16. 9/20/2013
DO NOT PROCEED UNTIL ALL TEST
CASES PASS!
Code committed to codebase
Code is committed to the codebase and can now be
built/deployed to the pre-production/staging
environment
14

17. 9/20/2013
QA tests in pre-production/staging
environment
QA runs through the test cases, primarily looking for
regression errors.
DO NOT PROCEED UNTIL ALL TEST
CASES PASS!
15

18. 9/20/2013
Before the iteration ends
Some form of a general regression should be run
before the iteration ends
DO NOT PROCEED UNTIL ALL TEST
CASES PASS!
16

19. 9/20/2013
After the end of the iteration
Deploy the code to
Production…
or not
In Summary
• 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
17

20. 9/20/2013
Questions?
18