Agile Testing with Lisa Crispin

My teammate Tony Sweets (sys admin, programmer and genius) just posted a terrific writeup of how our continuous integration and build process has evolved over the years. This includes a history of the hardware we’ve used and how the builds have been set up, both in CruiseControl and Hudson, and all the different things the build process does.

One of my favorite excerpts:

This method worked too well. The testers started splitting up their test suites and were creating new build jobs left and right mainly because it was so simple. They didn’t have to deal with hostname issues and whatnot. They simply had to create the new job from an existing Hudson job and change whatever they needed in order to run a different set of tests. When the job ran it did not care what else was running because it was running in its own separate environment.

I love the easy-to-use Hudson UI, and this freedom to configure our own test jobs the way we want. It’s also easy to stop jobs or kick them off when we want.

Whenever I speak to a conference session or user group meeting, I always tell people, “If you aren’t doing continuous integration now, go back to your office and drop everything and get your CI going. It isn’t hard to do, there are a bunch of good tools available to help, even Testify Wizard to help you set it up. A programmer can do it in a matter of days or less. There’s no excuse to not do CI.”

I’m convinced that in 5 years at the most, any team not doing CI will be looked upon the same way we look upon teams that don’t do source code control. It would just be crazy to not do it! Automated tests don’t have much value if they aren’t giving you quick feedback several times a day. Without CI, your technical debt is bound to bury you quickly.

If I had to pick one reason our team has been so successful the past 7 years, our CI process is it. It’s the pulse of our team, and if it stops (as it did a few weeks back – see Tony’s blog post!), we all just about have a heart attack! When it’s ticking along, we feel healthy and happy.

Rosie Sherry and Rob Lambert are doing a series of interviews, and asked me to fill out the interview questionnaire. You can see the results (and a great donkey picture) at the Software Testing Club Blog. Thanks Rosie and Rob, this was fun!

The Testing Planet from  the Software Testing Club has indeed landed! It is chock full of excellent articles about testing, both technical and cultural. Just a sample of the titles: “Yes, It’s Personal”, “Context-driven Jumping”, “Testing & Creativity”, “Weekend Testing Fun”. I am extremely proud that my article, an introduction to test automation design, is on the front page!

Though The Testing Planet is available digitally, I urge you to subscribe to the print version. 1) it is way more fun and convenient (at least for us folks who prefer an actual newspaper with our morning tea), 2) it supports the magazine, and we need to support it and keep it going! The Software Testing Club rocks, it’s a great way to meet and exchange ideas with testers all over the planet. Give a little back to your testing community by supporting The Testing Planet.

Methods and Tools

I wrote a tool review of FitNesse for the Summer issue of Methods and Tools magazine. Please let me know if you have any questions about it.

The summer issue of Methods and Tools has my tool review of FitNesse. Please check it out, and if you have more questions about it I’m happy to help.

My Agile Testing Days tutorial is almost full, so my motivation here is not to advertise it, but to invite you to meet one of my donkeys, Ernest. I tried to make the video with both Ernest and Chester, but it was very windy outdoors that day and Chester was fidgety, we couldn’t get a good video. My friend Anna suggested taking Ernest indoors to do the video, so we went in the living room and it worked just fine. It’s short, please enjoy!

Podcasts are a nice way to learn about new topics, pick up new ideas and hear the experiences of other testers and agile practitioners. I highly recommend the Testing Podcast site for informative interviews with a wide range of testing practitioners.

This interview with Michael Kircher of Software Engineering Radio was posted in June 2010 and can be found on testingpodcast.com as well, along with some other podcasts I’ve done in the past. Michael and I cover several topics ranging from the role of the tester in agile teams, over test automation strategy and regression testing, to continuous integration. I really enjoyed it because we got to talk for over an hour (though the podcast is not that long.)

InfoQ just published an article I wrote to try to inspire more testers to grow their skills. It begins:

The software industry is changing fast. More and more teams put testing up front and center; they use tests to drive development. New and improved automated test frameworks and drivers burst onto the scene every month. Teams with more automated regression suites need testers with sharp exploratory testing skills. But most people do not learn the needed skills in university: where will these testers come from? Read more…

Recently I tweeted about a fishbowl we conducted at the Business Analysis Workshop of the Better Software conference. Some tweeps weren’t familiar with the fishbowl format, so I thought I’d explain how I like to do fishbowls.

Fishbowl Discussion at BA Workshop, Better Software conference

Fishbowls are a good format for a panel discussion where you want to involve the whole audience, as well as a panel of pre-selected experts.

Put some chairs in the center of the room. They can face each other or, if the room isn’t set up for everyone to sit in a circle, face the audience. The number of chairs depends on the size of your audience. An average for a group of 20 people is five chairs. You’ll start with only four of the chairs occupied. Arrange the rest of the chairs in the room in a circle or semi-circle around the fishbowl.

If you have pre-selected panelists, have them sit down in the chairs leaving one chair empty. The rules are simple: anyone in the room can come sit in the empty chair. When that happens, someone else on the panel has to get up and return to the audience. Panelists may come and go by sitting in the empty chair whenever they want to join the debate.

The audience doesn’t participate actively in the discussion. You have to sit in the empty chair to start contributing to the discussion. The beauty of the fishbowl is that the audience gets to hear a variety of viewpoints, and anyone in the audience can choose to participate.

I’ve used fishbowls for panel discussions of controversial topics. Jean Tabaka recently facilitated a “Kanban vs. Scrum” fishbowl debate at Better Software, and allowed people to contribute via Twitter, as well. I’ve also used them for workshops where the participants are trying to come up with new ideas about a topic. For example, I might use a fishbowl format for a workshop where we try to think of better ways for development teams to elicit requirements from their customers. For my starting panel, I might choose people such as Elisabeth Hendrickson, Antony Marcano, Gojko Adzic and Jennitta Andrea, who are recognized experts in using customer-facing tests to drive development. They’re bound to have some good experiences to relate. But there’d also be a roomful of practitioners who have their own ideas and experiences, and with a fishbowl format, we get to hear from everyone.

Try a fishbowl at your next local user group meeting. It’s a great way for everyone to contribute, and it produces lots of valuable ideas from a variety of viewpoints.

If you’re at Better Software/ Agile Development Practices West this week, make sure you read the issue of Better Software that came in your conference bag. I’m especially pleased to have an article in this awesome issue with extraordinary fellow testers such as Jennitta Andrea, Markus Gaertner, Pradeep Soundararajan and Parimala Shankaraiah.

I’m a volunteer on the Diversity in Agile project founded by Mike Sutton and supported by the Agile Alliance.

For reasons I don’t understand, some people have misunderstood the first phase of the project, which seeks to recognize and celebrate the contributions of women in agile development, as an awards program for women. Some people even thought it was only for women in testing.

Jon Bach asked me a good question. A couple of weeks ago, our Writing About Testing group held a conference in Durango, CO. The group was nicely balanced with as many women as men. Jon asked me what advantages I felt this gave the conference. He found my reply helpful and encouraged me to share it here. I’ve done so, with edits to make it more understandable to people who weren’t there. I hope others will find it helpful.

(Some others are finding this still makes them uncomfortable. I guess this is just such a delicate issue, it’s hard to express my feelings without offending someone. But as we are losing women from our industry at an alarming rate, I feel like I have to take the risk of pissing a few people off. Please take this in the spirit that I have the best intentions at heart. And think about this – would you want to work on a homogeneous team? Yes, gender is only one part of diversity. It happens to be the first area that the Diversity in Agile project is recognizing.)

* * *
I’m sure the advantages of having a lot of women at WAT were different for each participant. And while I thought “wow, this is rare, I’m in a room with lots of women”, it wasn’t on my mind all the time.

For me, some advantages that may have been due to the gender balance were:

• I felt much more comfortable with a lot of women in the group. This wasn’t so much conscious, as just a feeling of ease and belonging that I don’t always feel on my almost-all-male dev team.
• I find women are in general more active at collaborating and communicating, especially in a new setting. I think we had a lot of good energy and jumping into the exercises and great conversations because we were a diverse group.
• Seeing other women contribute built my own confidence that I could contribute. I’m not saying that men in general try to reduce my confidence level. But I think most of us feel better with peers around. (Not to say men aren’t my peers – but they aren’t as much alike to me as other women are).
  
• This is a note I wrote down when Marlena Compton was talking, I’m not sure if she said it or if it’s just a thought she generated in me:
  • “It’s easy to not feel safe if you aren’t sure about your thoughts. You need a space safe enough to get thoughts out. “
• I feel more personal safety when there are more women in the room. I think it might be because other women are also thinking about safety, so they make an effort  to provide it. (Again, I am not saying that men do not care about personal safety or do not make an effort to provide it. I just don’t get the same feeling in a room full of only men.) Also in my notes is:
  
  • If you’ve got something to say, try to say it in a safe place. Don’t invest all your weight into your initial foray – get some feedback from a trusted peer group.
  • I’m not sure if Marlena said that but I’m pretty sure it was one of the women. So, generally I felt I was getting more support and information about personal safety and confidence from the women in the room.

• This is a gross generalization of course – but some men in the room talked about using anger as motivation for writing (which I do understand, it’s not a bad thing) while I felt women were coming more from a point of view of joy. For example, Elisabeth Hendrickson’s stunt hamsters and pandas added an element of fun.
  
• I feel that because there were so many diverse viewpoints in the room, I got a lot more ideas than from a group of only men. I can’t prove this, of course. But I’m thinking of Elisabeth’s slides with her panda and hamster people, Chris McMahon’s software development-as-artistic talk, the haiku exercise, donkey energy, the “P”s of motivation, we had a huge variety of ideas that I don’t think we’d have had with a less diverse group. (sorry, for those of you who weren’t there, I don’t have room to explain all those things, they will be blogged about later!)

I love the guys I work with, but I find I often have a point of view that’s different from theirs. Of course, it’s hard for me to know how much of my different viewpoint is just because I’m a tester. We’ve worked together so long, this has changed over the years, as we’ve all influenced each other.

But I remember at first, when there was only one other woman on the team, I was a bit shocked at the way they joked around – insults that were playful, but to an outsider it was a bit shocking, I couldn’t always tell if they were kidding. I don’t think they’d have had this aspect of their culture with more women around, though I could be wrong.

When all the guys play Quake every afternoon, and scream and cuss and pound the desk, they’re having a great time; the other woman on the team and I can enjoy that they are having fun, but we don’t feel like joining in. On a previous all-male team I worked with, I felt left out when they celebrated success by playing Foosball (which I’m no good at – though I do know women who love to play) or went to a movie I really didn’t want to go see (but I went anyway, which expanded my horizons – I learned to love X-Men!)  I really enjoyed having more women on my team back in the day when there were more female programmers.
* * *

I would appreciate any suggestions to make the Women in Agile site communicate our mission more clearly.

* * *

There are some other posts on this issue at CowboyTesting and Lanette Creamer’s blog,