The document outlines five tips for successful testing within agile teams, emphasizing the importance of collaboration and continuous quality assurance rather than following a traditional waterfall approach. Key advice includes avoiding the 'speed trap,' engaging in the '3 amigos' conversations for shared understanding, and supporting programmers in building quality into their code. Ultimately, testers are encouraged to act as quality champions to enhance product quality and customer satisfaction.

1. Neil Killick, Agile Coach and Trainer
neilkillick.com neil_killick
Copyright 2018 Neil Killick, Killick Agile Consulting Services
FROM QUALITY ASSURANCE
TO QUALITY CHAMPION
5 tips to be a
successful tester in
an agile team

2. SPRINT
BACKLOG DEV
READY
FOR TEST DONETEST
IT’S HARD BEING A TESTER
IN AN AGILE TEAM!
● Nothing to test at the start
● Developers throw stuff over the fence
● How do I test unfinished features?
● Automation means we’re not needed!
● It’s all on us - we’re the bottleneck! neil_killick

3. PENNY / COIN FLIP
GAME
A lesson in flow over busy-ness
and collaboration over solo effort
neil_killick

4. “OUR HIGHEST PRIORITY IS TO SATISFY THE CUSTOMER WITH
EARLY AND CONTINUOUS DELIVERY OF VALUABLE SOFTWARE”
~ MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT
● By working in parallel on a thing of value (e.g. a coin, a
story), we drastically reduce speed to market (1st and ALL
value to customer)
● This is why agile teams must be TRULY cross-functional
(remove phases / hand-offs and work collaboratively in
small batches)
BA
0:36
0:35
0:36
DEV
0:32
0:38
0:32
TEST
0:35
0:33
0:35
CUSTOMER
1:46
0:52, 1:12
0:02, 0:36
Batch
20
10
1
neil_killick

5. 1
DON’T LET THE TEAM FALL INTO
THE “SPEED” TRAP
neil_killick

6. QUALITY vs SPEED
● When working in an agile way, it’s easy to get carried
away with “speed”
● Limit your WIP to slow programmers down (and give
them time for quality)
● Prevents costly debugging (large batches) and
escaped defects
neil_killick

7. 2
DON’T BE THE “QA” OR
“TESTING” PHASE IN A
MINI-WATERFALL
aka “Shift Left”
neil_killick

8. QUALITY ASSURANCE is…
“the maintenance of a desired level of quality
in a service or product, especially by means
of attention to EVERY STAGE of the process
of delivery or production.”
neil_killick

9. QUALITY is…
● a SHARED responsibility of the development team, NOT only that
of the “QA”, “QA team” or “QA manager”
● a continuous, emergent attribute of the team’s (and
organisation’s) process and product - from mindset, behaviour
and interactions - NOT a phase tagged on at the end
● NOT tested into a product but BUILT IN
neil_killick

10. 3
FOCUS ON CONTINUOUS
TESTING OF THE PRODUCT
Not Just Checking Stories
neil_killick

11. Perfectly
checked,
NOT tested
neil_killick

12. Much of what gets called “testing”
is a subset of testing called
CHECKING
● Does the product behave how WE expect it to?
● We have implemented it to do z when user does y
in situation x - does it do that?
EXAMPLE - Given the customer has entered all the required bill
payment information, when they click pay bill, they should receive an
SMS verification code - do they?
neil_killick

13. TESTING
● Does the product behave how the CUSTOMER would want and
expect it to?
● Does it meet their needs?
● Centres on the DESIGN of the product, and the continuous
verification that what we build is both USABLE and USEFUL
EXAMPLE - Can the customer pay their bills quickly, easily and
securely using this bill payment feature? Can we make it simpler for
them?
neil_killick

14. ● Testers check AND test,
programmers should AT LEAST check
● Kill the notion of testers “testing
stories”
● Kill silos - collaborate on quality steps
in your process
neil_killick

15. 4
DRIVE THE “3 AMIGOS”
CONVERSATIONS
Build shared understanding of
“Ready”
neil_killick

16. “3 AMIGOS” (aka “STORY KICK-OFF”)
PRODUCT OWNER, PROGRAMMER and
TESTER (and UX PERSON?)
● SHOULD we kick off this story? (Capacity? Enough info?)
● What are the acceptance criteria? i.e. how will the PO
verify this story is “done”?
● What user scenarios are in this story? (slicing opportunity)
● What core behaviour should we check for?
e.g. integrations, business rules, boundaries, edge cases,
happy paths, failure paths
● Do we need any new acceptance checks? Or to modify
existing ones?
● Which checks can/should we automate?
neil_killick

17. ACCEPTANCE CHECK
SUITE
● Acceptance checks are at the heart of Agile
Software Development (hence ATDD)
● Share the artefact AND responsibility for it
neil_killick

18. Feature 1
Feature 2
DESCRIBE AT LEAST 1 ACCEPTANCE CHECK
PER FEATURE
Feature 3
Feature level
acceptance checks
neil_killick

19. Feature 1
Feature 2
Feature 3
neil_killick

20. Customer can pay bills
Customer can pay bills using credit card
Customer can transfer money between accounts
New acceptance check to
capture the new feature
Customer Can Pay Bills Using BPAY
neil_killick

21. Customer can pay bills
Customer can select one of their accounts
Customer can enter a valid biller code
Customer can enter a valid amount to pay
● > 0
● < Account balance
Customer can enter a valid billing reference
Customer can submit payment and receive
confirmation
Customer can transfer money between accounts
Lower level
acceptance checks
Customer Can Pay Bills Using BPAY
Customer can pay bills using credit card
neil_killick

22. Customer can pay bills
Customer can select one of their accounts
Customer can enter a valid biller code
Customer can enter a valid amount to pay
● > 0
● < Account balance
Customer can enter a valid billing reference
Customer can submit payment and receive
confirmation
Customer can transfer money between accounts
Customer receives SMS verification code
New acceptance
check, and modify
existing check, to
capture new
behaviour (2FA)
Lower level
acceptance checks
Customer can pay bills using credit card
Customer Can Pay Bills Using BPAY

23. 5
HELP THE PROGRAMMERS TO
BUILD QUALITY IN
Be The Change You Want To See
neil_killick

24. ● DON’T check unchecked code for the programmer
● Encourage them to WRITE checks to ensure their code does
what they intend it to - or AT LEAST to check their OWN and
INTEGRATED code
● Encourage them to fix (and prevent) bugs as soon as they are
found; No “bug tracking”
● Show interest; Show them the value of a collaborative approach
to quality
● Collaborate to find and use the right tools
neil_killick

25. DRIVE THE
DEFINITION OF DONE
During EACH Sprint Retrospective, the Scrum
team plans ways to INCREASE PRODUCT
QUALITY by improving work processes or
adapting the Definition of "Done"...
~ The Scrum Guide
neil_killick

26. ACceptance checks added/modified in
acceptance check suite
All code and checks deployed to production
All checks (automated and manual) pass in all
environments
All code meets team coding guidelines and is
peer reviewed
No known defects
neil_killick

27. 5 TIPS TO BE A SUCCESSFUL
TESTER IN AN AGILE TEAM
1. Don’t let the team fall into the “speed” trap
2. Don’t be the “QA” or “testing” phase in a mini-waterfall
3. Focus on continuous testing of the product (not just checking of
stories)
4. Drive the “3 amigos” conversations
5. Help the programmers to build quality in
neil_killick

28. BE A QUALITY
CHAMPION
AS A TESTER
I WANT TO HELP MY TEAM BUILD
HIGH QUALITY PRODUCTS
SO WE CAN IMPROVE OUR
BUSINESS AND CUSTOMERS’ LIVES
neil_killick

29. Neil Killick, Agile Coach and Trainer
neilkillick.com neil_killick
Copyright 2018 Neil Killick, Killick Agile Consulting Services