Download - Don’t Go over the Waterfall: Keep Agile Testing Agile

Transcript
Page 1: 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

Page 2: Don’t Go over the Waterfall: Keep Agile Testing Agile

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.

Page 3: Don’t Go over the Waterfall: Keep Agile Testing Agile

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

Page 4: Don’t Go over the Waterfall: Keep Agile Testing Agile

9/20/2013

2

Do your agile iterations look like this?

Or this?

Page 5: Don’t Go over the Waterfall: Keep Agile Testing Agile

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?

Page 6: Don’t Go over the Waterfall: Keep Agile Testing Agile

9/20/2013

4

What a 2 week iteration looks like to a developer

What a 2 week iteration looks like to a tester

Page 7: Don’t Go over the Waterfall: Keep Agile Testing Agile

9/20/2013

5

Sure sign that your Agile iterations aren’t agile

Ideal Burndown Chart

Page 8: Don’t Go over the Waterfall: Keep Agile Testing Agile

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?

Page 9: Don’t Go over the Waterfall: Keep Agile Testing Agile

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!

Page 10: Don’t Go over the Waterfall: Keep Agile Testing Agile

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

Page 11: Don’t Go over the Waterfall: Keep Agile Testing Agile

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

Page 12: Don’t Go over the Waterfall: Keep Agile Testing Agile

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

Page 13: Don’t Go over the Waterfall: Keep Agile Testing Agile

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

Page 14: Don’t Go over the Waterfall: Keep Agile Testing Agile

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

Page 15: Don’t Go over the Waterfall: Keep Agile Testing Agile

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

Page 16: Don’t Go over the Waterfall: Keep Agile Testing Agile

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

Page 17: Don’t Go over the Waterfall: Keep Agile Testing Agile

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!

Page 18: Don’t Go over the Waterfall: Keep Agile Testing Agile

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!

Page 19: Don’t Go over the Waterfall: Keep Agile Testing Agile

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

Page 20: Don’t Go over the Waterfall: Keep Agile Testing Agile

9/20/2013

18

Questions?