Agile Testing with Lisa Crispin

I always have a big stack of new agile books to read, and my most recent ‘read’ is a standout: The Agile Samurai: How Agile Masters Deliver Great Software by Jonathan Rasmussen. Here’s my review.

Reading The Agile Samurai, I felt like I was sitting with the author over a cup of coffee or a mug of beer, learning good ways to plan and develop good software products. The book has a fun and conversational style at the same time as it delivers serious lessons about software projects. The illustrations aren’t there just for fun (though they are amusing), they help to quickly explain the concepts.

Though I’ve been working on agile teams for 10 years and read countless books on the subject, I was surprised to find some tools and ideas in here that are new to me.  For example, I’d never heard of the “Inception Deck”, ten questions and exercises to get your software project off to the right start. It looks like an excellent approach. I also like the idea of creating a  “product box” to focus on what’s compelling for your customers and on the benefits of your product.

One thing I appreciate about The Agile Samurai is how the author incorporates ideas from many disciplines, such as Lean. Even more valuable are the many anecdotes from the author’s experience. One theme I found in the book is the need to deal with reality, and it’s helpful to have real-world examples.

I particularly enjoy the little conversations between the “Master Sensei and the aspiring warrior” that wrap up each chapter. You had the same questions the aspiring warrior asks! This is a fun way to explore the confusing aspects of agile development.

If you’re new to agile, you might as well know the truth right from the start, and this book is grounded in reality. Yes, high-level estimates ARE guesses, as the author says, “usually really bad, overly-optimistic ones”. Meet the Cone of Uncertainty! But the author gives us a way to estimate to acknowledge all this but still help us plan.

Here’s one of my favorite paragraphs in the book:

Just don’t be strong-armed or bullied into committing something you and the team can’t deliver. That’s not doing anyone any favors. And this collaboration thing has to be two-way. Just be honest, and tell them what it’s going to take. [The Agile Samurai, p. 148]

This book really will help you deliver something of value every week. It covers many critical techniques in a surprisingly comprehensive way, giving the reader suggestions for additional reading. Agile newbies will learn accurate and useful information about everything from XP practices to Kanban, as well as where to learn more about all that. The author puts agile concepts together to come up with practical advice, such as how to create a visual workspace.

In my view, the book ends with the best possible advice: “Don’t worry about being agile”. The author gives you many tools and techniques, and prepares the reader (or “aspiring warrior”) to figure out what is best for that individual and that project. We shouldn’t worry about being “agile”, we should indeed aim to build great products and deliver great service to our customers. To paraphrase the author, get out there and start reading this book, then get out there and start doing it!

On Tuesday, November 9 at 1:00 PM EST, I’ll be on a SmartBear Software -sponsored panel discussion Webinar with Steve Berczuk, Jason Cohen and Esther Schindler (who will serve as our moderator) talking about how to improve software quality. Steve, Jason and I approach quality from slightly different angles so this should be interesting and fun! You have to register, but it’s free, and you can ask questions via the Webinar UI. Please join the discussion!

The new issue of Agile Record has an article of mine, one I’ve been wanting to write for a long time. It’s not the best-crafted article I ever wrote – I was in a rush to make the deadline (actually I missed the deadline, but the editors were nice and included my article anyway). However, it’s an article that’s close to my heart.

Lisa and Chester

If you’ve ever heard me speak, you’ve probably heard me refer to my donkeys as an example of the importance of trust, or enjoyment of work. I wanted to explain all the insights I’ve gained from my donkeys and applied to agile software development, and I finally sat down and wrote this article. Please enjoy it, and let me know what you think.

My teammate Tony Sweets (sys admin, programmer and genius) just posted a terrific writeup on StickyMinds/Techwell 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.

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.

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…

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.

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!

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.

Why We Learn

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!

What We Need to Learn

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.

How We Can Learn

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

More Photos

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.