Pairing with Developers from STPCon 2010 by Lanette Creamer

1. White Master
Pairing with Developers
Lanette Creamer
Sogeti Senior Consultant
testyredhead.com

2. Contents
What is a developer anyways?
Who are we?
How and why we started pairing.
Why we continued.
When we finished.
Our informal retrospective results.

3. You will leave with
At least one idea of how to start pairing.
A real example that worked in practice.
Two contacts who can help you.
Ideas that can be adapted to any context.
Ways to challenge existing role definitions.

4. Loading Project Background
1st Agile Project
Scrum Master Training (Woof)
Quality Initiative Dynamics
Distributed undersized Team with non-iterative goals
Very Late Delivery Expected
Grandiose Unit Test Coverage Planned

5. Testing Limbo

6. Define Software Developer
Anyone who codes?
Production code?
What about TDD?
Are tests part of production?
What about the code we didn’t write?
Integrated components?
Interacting with existing databases?

7. Software Developer?

8. Software Developer?

9. Software Developer?

10. Tester or Developer?

11. Developer Instance
Meet Marty
& his son.

12. Developer Instance
Marty is a Developer who tests sometimes.
His website is http://www.theflexguy.com/
He makes testing tools and flex applications at
Adobe. Still, he is not the tester in this case. He is
the tools developer.

13. Define Software Tester
The tester is the person taking action to obtain
and provide current information about the
suitability of the product for the intended use by
performing tests.

14. Tester Instance

15. Tester Instance
Me.
Prior experience on agile projects == 0
Prior experience testing Flex Apps == 0
Prior coding experience?
Some .bat files
A few fancy excel spreadsheets
A few mouseovers in ActionScript

16. Tester or Developer?

17. The Start of Pairing
What is the URL for that dashboard you are
working on?
It’s not really ready for test yet.
I understand, but can you show me what you are
working on so I can think of some test cases?
Sure! I’ll walk you through it!

18. How to start-Just go

19. Testing before Testing?
A test can be a question that hasn’t been
considered.
A test can be challenging an assumption someone
didn’t know they made.
A test is any question you can think of that the code
may not yet answer.

20. Pairing-Advantage Test
I came up with some tests and some questions.
Why don’t you stop by and we’ll go through them
together.
Do you know how I could post some good data to
test the limits of _________?
How can I compare this value to know what I’m
seeing is right?

21. Avoid Pitfalls

22. Pairing-Advantage Dev
These parts are ready for some testing, but these
areas aren’t hooked up yet. Stop by and I’ll walk
you through it.
During small demo-What happens if? Why is it
showing that? Where is that time coming from?
Let me show you. Here I get the time and I pass
it,..wait? I did WHAT? Here, I can change that.

23. Hurricane Season?

24. Pairing-Advantage Both
He showed me how to post a build.
I got source control to look at his changes
because I had to in order to post my test files.
He showed me how his dashboard used the
metadata.
I found an example Python script and went to
town making ugly non-object oriented code, but
everyone got an automated acceptance test!
From that ugly first test we worked together &
automated shipping all products at once!

25. Puzzles

26. Pairing-Why did it work?
A willing teacher who values testing skill.
A tester who understands the basics of
programming. Someone who can’t write pseudo
code and understand it should not try a code
walkthrough.
More coding experience is better, but it doesn’t
negate the value of an early test perspective.
My code got better, and his code was stable
much sooner when the test expectations were
built in.

27. Unlocking & Unblocking

28. Why not just code review?
Marty left me a great comment about my
automation. He was excited.
Thanks for the comment, but I have no idea how
to do that. In fact, it isn’t even a word in my
vocabulary?
Oh. Research these three things before our next
pairing.
The code changes we made together made my
automation go down from taking 2 hours to
running in less than 2 minutes. Pairing is more
than a review.

29. Passes Code Inspection?

30. Isn’t it a waste of time?
If you have a dev who thinks it is a waste
If you have a tester who is afraid to be wrong or
look a fool
If your goal is to have maximum documentation
over speed and learning
If your employees gaining new skills isn’t as
important as your very best people never being
interrupted
If mentoring isn’t seen as a priority or rewarded
It could be.

31. Good Enough?

32. Good Enough?

33. Do
Try pairing for a short time with many people.
Respect that not everyone wants to pair.
Ask for feedback on what is most productive and
adjust the focus from time to time.
Find the right time of day. 11am and 2pm were
good for us. 9am and 4:30pm sucked.
Start small. We met just once a week for an hour
at a time sometimes. It was enough to keep the
pairing going through the project.

34. Do

35. Don’t
Make a mandate.
Say all coders must test, all testers must code.
Say it is a choice, then layoff or demote anyone
who doesn’t oblige.
Insist that every pairing produce a deliverable.
Some of our best stuff only produced ideas to go
work on by ourselves.
Make introverts work with a tester staring at them
all day (awkward!) Agile Nazis are still Nazis.

36. Don’t

37. Marty Says
“Explaining the function of the code helped flush
out potential problems early on. Also, having
another perspective helped pull my nose off the
grindstone to get the big picture, which is good
for keeping the project going in the right
direction.”

38. Marty Says
“As a developer, it is very easy to get lost in your
own little world, and you can develop blinders to
the big picture. Working with someone else,
especially a tester who can bring to the table a
completely different perspective, can improve the
quality of an application much faster than working
alone. I’m going to look for more opportunities to
pair routinely now that I see and reflect on the
value of it.”

39. Summary
Before you can test the code, you can test the
product if you expand what a test is.
Developers can make code more testable by
pairing with the right testers.
Teamwork can be good for productivity, morale,
and cross training your team.
It doesn’t matter if it is test code or product code.
You need quality craftsmanship for both.
Pairing works well when you let the amount ebb
& flow as needed.

40. Q&A
Lanette.creamer@gmail.com
http://blog.testyredhead.com
Twitter @lanettecream