Testability Squad
Health Check
Based on the 10 P’s
of Testability by
Rob Meaney
More in the ‘Team
Guide to Testability’
on Leanpub. By Rob
Meaney & Ash Winter
Squad Health Check model
version 1, September 2014
What is this?
• A workshop & visualization technique for helping squads* improve
Who is it for?
• The squad itself
• People supporting the squad (managers, coaches, etc)
How to use the model
• Print the cards & laminate
• Slide 2-5 = Awesome Cards (double sided)
• Slide 6-9 = Voting cards (double sided)
• Get the squad together in a room
• Discuss the Awesome Cards. Each one is a health indicator
with an “example of awesome”, and an “example of crappy”.
• Ask the squad how they feel about each health indicator,
using techniques such as voting cards.
• Green doesn’t mean Perfect. It just means the squad is happy with this
and see no major need for improvement right now.
• Yellow means there are some important problems that need addressing,
but it’s not a disaster.
• Red means this really sucks and needs to be improved.
• Also discuss the trends (are things improving, stable, or getting worse?)
• Visualize the result, for example like this:
• Use the data to help the squad(s) improve
Tips
• These cards are just a starting point. Squad is free to
add/remove/tweak the questions to match what they think matters.
• Make sure this is used to support the squads, not judge them!
* Squad is Spotify’s term for a small, cross-functional, self-organizing development team
Credits:
• Health check model: Henrik Kniberg & Kristian Lindwall,
with help from the other agile coaches at Spotify
• Graphical design of cards: Martin Österberg
• Icons by https://www.behance.net/rudityaswahyu
Feel free to spread/modify/reuse this model! Creative Commons
Attribution-ShareAlike
People
We possess the skills
and knowledge to do
great testing!
We don’t have the skills
needed or access to a
testing specialist
Philosophy
The whole team takes
responsibility for
testing.
Let's be honest, if the
testers don’t do any
testing, we don’t test
anything.
Product
The product is designed
to help us both explore
and automate our
testing at many levels.
Limitations in our
design mean we only
used limited testing
techniques.
Process
We work on small,
releasable chunks with
limited debt at a
sustainable pace.
Large chunks with no
idea about the risks
introduced to
production.
Problem
We empathize deeply
with the problem or
opportunity our features
address for our
customers.
There is no time to
understand customer
needs, only to spec
delivery matters.
Project
We have the time,
resources and autonomy
to do great testing.
Testing is last minute,
always crunched at the
end, automation is done
to best endeavors.
Pipeline
Our pipeline delivers
builds reliably where we
want them, when we
want to test.
We fight to get builds to
the environments we
want with other teams.
Which never run first
time anyway.
Productivity
We test continuously
and find important
problems early in the
development cycle.
Testing takes a long
time to get started, we
context switch and
important problems
appear just before
release.
TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK
TESTABILITY HEALTH CHECKTESTABILITY HEALTH CHECKTESTABILITY HEALTH CHECKTESTABILITY HEALTH CHECK
Production Issues
Very few production
issues which are fixed
quickly.
Lots of production
issues which cause
downtime and have a
long time to recovery.
Proactivity
We regularly reflect on
how and what test and
adjust accordingly.
Our test strategy is the
same as it was when the
team was created years
ago!
TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK
TESTABILITY HEALTH CHECKTESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK
Testability Squad Health Check
Testability Squad Health Check
Testability Squad Health Check
Testability Squad Health Check
Testability Squad Health Check
Testability Squad Health Check
Testability Squad Health Check

Testability Squad Health Check

  • 1.
    Testability Squad Health Check Basedon the 10 P’s of Testability by Rob Meaney More in the ‘Team Guide to Testability’ on Leanpub. By Rob Meaney & Ash Winter
  • 3.
    Squad Health Checkmodel version 1, September 2014 What is this? • A workshop & visualization technique for helping squads* improve Who is it for? • The squad itself • People supporting the squad (managers, coaches, etc) How to use the model • Print the cards & laminate • Slide 2-5 = Awesome Cards (double sided) • Slide 6-9 = Voting cards (double sided) • Get the squad together in a room • Discuss the Awesome Cards. Each one is a health indicator with an “example of awesome”, and an “example of crappy”. • Ask the squad how they feel about each health indicator, using techniques such as voting cards. • Green doesn’t mean Perfect. It just means the squad is happy with this and see no major need for improvement right now. • Yellow means there are some important problems that need addressing, but it’s not a disaster. • Red means this really sucks and needs to be improved. • Also discuss the trends (are things improving, stable, or getting worse?) • Visualize the result, for example like this: • Use the data to help the squad(s) improve Tips • These cards are just a starting point. Squad is free to add/remove/tweak the questions to match what they think matters. • Make sure this is used to support the squads, not judge them! * Squad is Spotify’s term for a small, cross-functional, self-organizing development team Credits: • Health check model: Henrik Kniberg & Kristian Lindwall, with help from the other agile coaches at Spotify • Graphical design of cards: Martin Österberg • Icons by https://www.behance.net/rudityaswahyu Feel free to spread/modify/reuse this model! Creative Commons Attribution-ShareAlike
  • 4.
    People We possess theskills and knowledge to do great testing! We don’t have the skills needed or access to a testing specialist Philosophy The whole team takes responsibility for testing. Let's be honest, if the testers don’t do any testing, we don’t test anything. Product The product is designed to help us both explore and automate our testing at many levels. Limitations in our design mean we only used limited testing techniques. Process We work on small, releasable chunks with limited debt at a sustainable pace. Large chunks with no idea about the risks introduced to production. Problem We empathize deeply with the problem or opportunity our features address for our customers. There is no time to understand customer needs, only to spec delivery matters. Project We have the time, resources and autonomy to do great testing. Testing is last minute, always crunched at the end, automation is done to best endeavors. Pipeline Our pipeline delivers builds reliably where we want them, when we want to test. We fight to get builds to the environments we want with other teams. Which never run first time anyway. Productivity We test continuously and find important problems early in the development cycle. Testing takes a long time to get started, we context switch and important problems appear just before release. TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECKTESTABILITY HEALTH CHECKTESTABILITY HEALTH CHECKTESTABILITY HEALTH CHECK
  • 6.
    Production Issues Very fewproduction issues which are fixed quickly. Lots of production issues which cause downtime and have a long time to recovery. Proactivity We regularly reflect on how and what test and adjust accordingly. Our test strategy is the same as it was when the team was created years ago! TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECKTESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK TESTABILITY HEALTH CHECK