“I’m both a tester and a programmer. And I don’t see anything wrong with testing my own code,” says Agile guru Elisabeth Hendrickson in this second part of a two-part interview with SSQ’s Agile expert, Lisa Crispin. For the first part of this interview, see Q&A: Exploratory testing, regression testing and automation.
Lisa Crispin: You’re the driving force behind Entaggle, a website where we can give and get recognition from our professional peers. Can you share some ways you do exploratory testing on the Entaggle software, and how it helped the product?
Elisabeth Hendrickson: Whenever I get to a good stopping point in writing a new feature, I spend time exploring. Sometimes I explore on my local box, and sometimes on my staging server. But I always explore before I push changes into production. In doing so I have found any number of instances where I thought I was close to “done” but had actually missed cases that would have caused serious problems. In fact, I have a change that I would like to push to production right now, but when I explored it on staging I found a serious crash bug. So I’ll be fixing the bug before I take the code live.
Some people ask me if I don’t see a contradiction between the programmer and tester hats I wear when working on Entaggle. “Programmers might be able to test,” they say, “but they can never test their own stuff. They’re too biased.”
I don’t think that’s true. I’m both a tester and a programmer. And I don’t see anything wrong with testing my own code. It’s a matter of perspective. I think about a feature differently when I’m programming it from when I’m testing it.
However, I have learned that while testing my own stuff isn’t a problem, testing when I am in a hurry is.
I have missed bugs. And most of the time, if I ask myself how I didn’t see the problem when I was exploring, the answer was not that I was too close to the code. Rather I was blinded by my eagerness to push the feature into production. When I take my time exploring, I can release with significantly greater confidence.
This most recent bug is in a big, hairy, and much-requested feature (invitations). It took me quite a while to implement the invitation feature compared to other stories. There are a lot of moving parts. And after all the time I spent working on it, I really wanted to see the feature in production. For that matter, I wanted to use it myself. So I allowed my eagerness to overwhelm my caution. And guess where I’m seeing the issues? You guessed it: in the feature that I rushed into production.
I think the lesson here applies not just to individuals like me who wear many hats, but also to organizations. When an organization wants to “save time” or “release sooner” by cutting testing time short against the recommendation of the team, they’re asking for trouble.
Crispin: You’re a driving force behind the Agile Alliance Functional Test Tools (AA-FTT) group. Will you be involved in the AA-FTT workshop at Agile 2011? Where do you see this group taking our community?
Hendrickson: You’re too kind! Jennitta Andrea founded the AA-FTT. I’m a co-chair and cheerleader. (I like to say that I am merely Jennitta’s minion, but she gets annoyed with me when I say that.) Others in the community are driving forces as well. Gerard Meszaros in particular has been working with Jennitta and me a great deal recently.
But to answer your question, I will definitely be involved in the AA-FTT workshop at Agile 2011. I’m really looking forward to it! Ainsley Nies, an experienced Open Space facilitator, has agreed to facilitate for us. It should be an awesome meeting.
As for the future…
The group’s mission is to support the community in advancing the state of the art and practice for functional testing tools on Agile projects. That mission is not changing, but we’re finding better ways to accomplish our goals.
Last October, we held a meeting in London where Linda Rising led us through a patterns workshop.
In this instance, “pattern” refers to design patterns: worked solutions captured in a form that conveys more than just a solution. Patterns also describe the context in which the solution is applicable, the problem the solution addresses, the forces that affect the solution, and the resulting context.
Since that first workshop, Jennitta and I, along with several other members of the community, have been focusing on patterns for ATDD / BDD. We held a second (short) pattern workshop in Berlin (as you know since you were there), then held a two-day workshop at my studio in Pleasanton, CA this spring.
Having now done these workshops, we’re more convinced than ever that patterns are a particularly powerful way of sharing solutions to common problems.
So you can expect to see a lot more about patterns coming out of the AA-FTT in the next year.
Elisabeth Hendrickson is the founder and president of Quality Tree Software, Inc., a consulting and training company dedicated to helping software teams deliver working solutions consistently and sustainably. She also created Entaggle, a community-based site for giving and getting professional recognition. And she founded Agilistry Studio, a practice space for Agile software development in Pleasanton, CA.
A software professional for over 20 years, Elisabeth has been a member of the Agile community since 2003. She served on the board of directors of the Agile Alliance from 2006 - 2007 and is one of the co-organizers of the Agile Alliance Functional Testing Tools program. Elisabeth splits her time between teaching, speaking, writing, programming, and working on Agile teams with test-infected programmers who value her obsession with testing. You can find her on Twitter as @testobsessed.