Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Pairing w developers_stpconpics

on

  • 8,284 views

Pairing with Developers from STPCon 2010 by Lanette Creamer

Pairing with Developers from STPCon 2010 by Lanette Creamer

Statistics

Views

Total Views
8,284
Views on SlideShare
1,119
Embed Views
7,165

Actions

Likes
0
Downloads
9
Comments
0

7 Embeds 7,165

http://blog.testyredhead.com 7157
http://webcache.googleusercontent.com 2
http://seoautomated.com 2
http://www.bing.com 1
http://translate.googleusercontent.com 1
http://www.google.co.uk 1
http://www.ranksit.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Pairing w developers_stpconpics Pairing w developers_stpconpics Presentation Transcript

  • Pairing with Developers White Master Lanette Creamer Sogeti Senior Consultant testyredhead.com
  • 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.
  • 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.
  • 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
  • Testing Limbo
  • 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?
  • Software Developer?
  • Software Developer?
  • Software Developer?
  • Tester or Developer?
  • Developer Instance Meet Marty & his son.
  • 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 a tools developer.
  • 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.
  • Tester Instance
  • 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
  • Tester or Developer?
  • 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!
  • How to start-Just go
  • 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.
  • 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?
  • Avoid Pitfalls
  • 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.
  • Hurricane Season?
  • 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!
  • Puzzles
  • 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.
  • Unlocking & Unblocking
  • 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.
  • Passes Code Inspection?
  • 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.
  • Good Enough?
  • Good Enough?
  • 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.
  • Do
  • 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.
  • Don’t
  • 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.”
  • 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.”
  • 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.
  • Q&A Lanette.creamer@gmail.com http://blog.testyredhead.com Twitter @lanettecream