3. Alexandra & Era of Pair Testing on
Shared tasks done
side by side
Sharing as we go
vs. Debriefing at
4. Willingness to
try new things
See: Carol Dweck
Static, like height
Defines your identity
For those with no talent
Can grow, like muscle
Seek and embrace
Path to mastery
Reaction to challenge
5. Learning to Pair
On tasks that mix
novice and expert
Specific style of
Realizing pairing is
6. Strong Style Pairing
“For an idea to go from your head to
the computer it must go though
someone else’s hands”
12. My Team
“I get more done
“I could try pairing
(but not with you)” “Back to
“Ask if you need
need to progress”
Pair programming is a core agile technical practice. Many people still have reluctance to pair, pair only with people they choose, only on specific types of tasks or only in case of emergency. I am one of those reluctant people pairing selectively. This talk is about deliberate practice in building up the skill of pairing to allow pairing to take one’s skills on other activities to a new level.
In this session, you will learn about my different stages of pairing and lessons picked up as a testing specialist. The talk goes through a growth patterns from pairing with peers (other testers) to pairing and mobbing with developers, from traditional style and side-by-side work to strong-style pairing and to pairing on both testing and programming activities.
Join me on my journey to realize that explaining isn’t the same as experiencing. Pairing is sharing on a different level, but to make the ride smooth, there’s skills to develop and styles to consider.
“there’s a process of knowing” – learning
Does not give as regression; serendipity (safety against things happening randomly) / unwanted serendipity events.
This is what it is and what it could be. There’s a direction to it, not just statement of what it is.
Coaching is not just feedback, it’s pointing them to the right way.
EXPERIENCE (the verb) rather than facts ; emotions over facts. REACTIONS.
HISTORY, Lessons learned, checklists. Modeling.
UNDERSTANDING – where you start (knowing the thing (code & environment), knowing the user, knowing the problems, knowing the developers (how to help them and what they do so that you can efficiently test), knowing the hackers (weird use cases outside common ‘have you tried reading it upside down’) , knowing all stakeholders, knowing the business priorities)
Uncovering things I cannot know, giving the application a change to reveal information for me.
This allows you to know things.