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,

Please see my StickyMinds Blog for a new post inspired by Jeff Patton’s recent presentation to our Agile Denver user group. The Whole Team Approach isn’t just for developing the software! We need to really think Whole Company. Comments welcome!

I’ll be speaking at the Norwegian Developer Conference June 16 – 18 in Oslo. The conference puts out a free magazine which includes my article about Learning for Testers, along with lots of great articles from other speakers such as Jurgen Appelo, Roy Osherove and Chris Sells. The speaker lineup includes lots more exciting practitioners and experts: Mike Cohn, Brett Schuchert, Uncle Bob Martin to just name a few. If you plan to attend, please let me know, I’d love to see old friends and meet new people there!

The Software Quality Association of Denver held a workshop May 7 to share ideas about why testers need to learn, what they need to learn, and how they can learn all of that. I facilitated an enthusiastic crowd of about 80 people. The room wasn’t set up in a suitable way, but participants found creative ways to work. And creative they were. I’d like to summarize some of the outcomes.

We started by dividing into small groups to brainstorm the reasons why testers need to learn. Beyond the obvious “stay employed” and “do your job better”, some fascinating reasons came out: “To stay interested and sharp”, “self-esteem”, “curiousity”, “freedom” – I’ve always thought that job security is in your mind. If you believe you have valuable skills, you’ll know you can get a job no matter what happens. Now, that’s freedom!

Group Brainstorming Activity

Other reasons that I might not have thought of included: Help others learn,  keep up with changing environments and be more flexible and adaptable, spawn new ideas. “Challenge yourself”, “Be a better contributor” – this is the attitude I want in my peers! There were several comments on the theme, “avoid reinventing the wheel” – find out what works and what doesn’t, build on previous learning and trials, make work easier and more efficient.

Another theme was “prevent stagnation”: keep your brain young, become more well-rounded, balance working hard with getting help when needed, be ready for the next opportunity, job satisfaction, and one of my favorites: “It’s fun to learn”. Well, yeah!

Our second group activity was to think of all the things we need to learn. I was gratified to see a lot of what some people call “soft skills”, what Diana Larson and Jim Shore call “essential skills”: negotiation skills, listening skills, stress management, leadership skills, management skills, team mentality, how to motivate people, conflict resolution, creative problem solving, how to work with developers, communicate without jargon, simplify concepts, how to think like a customer, politics, team dynamics. An especially intriguing item was “Who tells the truth?” It’s critical to know that, right?

Creative Use of Body and Chair for Brainstorming Surface

Flexibility and versatility were a theme here. Design patterns, programming/scripting languages, platforms, levels of abstraction, being able to speak the developers’ language were important outcomes. “Keep your brain in good learning shape” is something essential that hadn’t occurred to me before. One group noted the importance of learning estimating and planning skills. Long lists of test tools, processes, methodologies and other technical skills were also popular items on the “What to learn” lists.

This all sounds wonderful, but how do we learn all those diverse skills? Where do we find time to gain that experience? In our third group activity, the SQuAD groups came up with lots of innovative ways to learn.

One theme was trial and error. Learn from mistakes – what worked, what didn’t. Retrospectives are one way to do this. Experiment, do pilot projects, and importantly, build slack into the system so you have time to do this. A learning culture where mistakes are tolerated is a prerequisite for innovation and creativity.

Mentoring was another common theme, but a twist on this was not only to get a mentor, but to be a mentor. Mentor the tester next to you! Learn by teaching.

Collaborating within and across teams is another learning method that several groups came up with, but again with different ideas. Creating a shared space and being able to sit with people that have different skills is a great way to learn. Using wikis for collaboration is another. Pairing with other testers and with developers was suggested. Getting feedback from coworkers is another simple but effective idea. Our peers are a great resource.

If the sticky notes won't stick, brainstorm on the floor!

Participants had a lot of interest in learning about their business, learning the domain. To do this, they suggested brown bag lunches with Subject Matter Experts, using the product like a customer would, talk to experts, observe. One of my favorite ideas was “Write a manual!”

Some outcomes built on our existing skills that already help us be good testers. We’re good at asking questions, so ask! Ask followup questions. Learn about the product with exploratory testing. Do compoarison testing. Evaluate tools to learn more about them.

There are obvious online sources of information, such as webinars, podcasts, blogs and white papers. I was surprised how many groups listed “Google” and online searching as a way to learn (though it shouldn’t be surprising – we all do that all the time!) Social networking also came up a lot as a good way to get information and benefit from others’ experiences. In addition to mailing lists, we have many online communities at our disposal, such as Software Testing Club and Weekend Testing.

One group suggested applying principles from non-related areas. Our reading and learning shouldn’t be limited to testing or even software development. Inspire yourself by attending (in person or virtually) conferences such as TED: Ideas Worth Spreading.

I was gratified to see several groups suggest that we learn by doing. “Practice!” The best way to learn is just go ahead and try something.

Outcomes on Door

You can see the groups at work, and their ideas, on my Picasa site. Please take a look and think about what you will do today to learn something new.