Agile Testing with Lisa Crispin

On March 24, I facilitated a workshop at Agilistry Studios in Pleasanton, CA, on Learning for Testers. 19 practitioners from the Bay Area got together to consider how, as testers, we can learn ways to contribute more to our teams, as well as raising the bar for our profession. I’d like to share some of the ideas generated by this engaging group!

Why We Should Learn

We started out by considering good reasons that testers should learn. Participants self-organized into groups, brainstormed ideas, and each group chose their top three ideas to share. Some of the items surprised me. One reason to learn was “to reduce stress”. I asked the group to elaborate. They pointed out that it is stressful if you aren’t sure whether you have the appropriate skills to do your job. That is so true, I have felt that stress before!

Another category of reasons that resonated with me was “to have fun” and “not to be bored and have ADD”. Finding joy in our work should be our highest priority IMO!

Rather than take up room on this page, I invite you to see the photos of the actual results on my Picasa site.

What We Should Learn

I love the Bay Area, it is truly a crucible of software creativity. It is no surprise, therefore, that the ideas of what to learn were surprising to me.

“Knowing when to stop” – wow, so true. Any good tester can find things to test forever. When have we achieved the “minimum”? What is “enough”? Given that in real life, we have time and resource limitations, this is a crucial skill.

“How to invent test ideas” – cool!

“Deciding what is most important to test” – that kind of ties in with “Knowing when to stop”, I think. Knowing how to analyze risks, learning customer and user priorities, these are necessary skills for testers.

I was glad to see “thinking skills” were a priority, such as: Communication, Integrity, How to Teach. Integrity is particularly interesting to me. It’s essential, but how do we learn it? How do we teach it? Comments, please!

Another interesting skill to learn was the “Elevator Pitch”. If you can describe what you do in under a minute, you must really understand it. This exercise produced many intriguing skills – please check out the photos of the sticky notes.

How To Learn These Things?

I think the most innovative ideas in this workshop surfaced during the “How To” brainstorming.

Consider this: “Note your assumptions. Later, compare what happens to your assumptions. When you stop, note your reasons for stopping. Mindfulness.” I don’t know about you, but I am going to try this.

Journalism class, to learn how to make elevator pitches – what a great idea! We have to go outside our profession to get skills that will help us do our best work.

Risk taking – set out to fail! This takes a lot of courage, but failure is a great way to learn, so why not?

And finally, my favorite, “Learn by doing”. Isn’t that the best way? But to learn, we need time. If we’re always focused on meeting deadlines, we won’t absorb any learning.

Make some room today for learning. Your team has the best solutions to your problems. You just need to take the time to talk about them and think of small experiments (as Linda Rising says) to address them.

My colleague and co-author Janet Gregory and I have a new article in this month’s Better Software about Learning for Testers, with some additional material on Techwell.com. We’d love to know what you think, please comment!

I wrote up my experiences at the excellent Belgium Testing Days conference which took place in February. In particular, I thought about what is different for me at conferences outside the U.S. compared with “domestic” conferences. They’re all great learning and networking opportunities, but culture makes for some nice differences. Overall it was a wonderful time and I’m still thinking how to apply everything I learned. Read about it on SearchSoftwareQuality.

This past Saturday I was fortunate to be one of the 60 people enrolled for the largest Code Retreat ever, Code Retreat Boulder, facilitated by Corey Haines and Chad Fowler, organized by Prakash Murthy. This was my first Code Retreat, though I’ve worked on teams practicing TDD, pair programming, and good design practices for more than ten years.

I was the only tester attending, and as I had feared, I was somewhat out of my depth. Nevertheless, I write automated tests, and I need to apply the same design basics to those as we do to production code. The past couple of years, I’ve tried to think of ways to help testers learn those principles, and written articles such as “An Intro to Test Design” in the Testing Planet. One goal of Code Retreat is stretching yourself, making ugly messes and not worrying about it even though our goal is perfection. I was definitely stretched way beyond my comfort zone!

Corey explained the basics we should practice:

1. Tests pass – J.B. Rainsberger says this is “like breathing”.
2. Don’t Repeat Yourself, keep code DRY
3. Tests and code reveal intent – name things well
4. Small – work in tiny increments.

The day was divided into 45-minute pairing sessions; we switched pairs each time. We wore name tags that indicated our programming language preferences. At the end of each session, we had to delete our code, stand up, and debrief for a few minutes about what we learned and what to try next. We also had a long lunch break (with delicious food!) The coding problem to solve was Conway’s Game of Life. As I dislike both math and puzzles, this scared me.

Mike Clark generously offered to pair with me in the first session. I’ve known Mike for ten years and he’s a TDD guru. We used RSpec and TextMate, both new to me (at work, we use test::unit with Ruby, and I use IntelliJ Idea). It was so natural for Mike to start writing a tiny test, then a tiny bit of code, which he put in the same file to start off – quite efficient. He had brought graph paper, which was handy for writing down examples of what a Game of Life grid would look like. We immediately set about creating and testing a board of cells. Corey came around to look at what we’d done, and commented that we should try to avoid numbers and X/Y coordinates. Hmmm. He mentioned encapsulation, which I understood to mean we don’t need to know about cells, only the board.

Apparently most everyone had started out creating a grid and using X/Y coordinates. For the second session, I paired with Erika Bricey, who works at Rally Software. We decided to follow Corey’s advice to start with the rules, to focus on the names for the methods, and whether the methods are doing too much. Corey mentioned that a class with plural name is a collection of other things. Erika and I had some good ideas on how to approach the problem, but for sure I couldn’t turn those into code, and Erika struggled too. Erika also used RSpec, but she worked in Eclipse.

Seeing our frustration, Corey and Chad suggested we less skilled persons find highly skilled pairs. So I waylaid Marty Haught, a test-obsessed programmer I’ve been wanting to talk to. He went along with my desire to focus on rules and on the names of things. For example, we started out with a module called “alive”, for cells that are alive. Later we needed to have dead cells, so we renamed that to “remain_alive” and the other module was called “dead_cell”. We wrote tests and code for most of the rules. We tried to follow Corey’s advice that “anytime you need to DO something, ASK another object”. For example, to find out if a cell is alive, ask “How many neighbors do I have?” and that will invoke an object that says “Here’s my number of neighbors, am I alive?”

Corey told us that if every time you have to make a decision, you ask someone(thing) else, you end up with no “if” statements. He challenged us to see how far we could go before we had to have a number. He noted that there are two parts to the rule: the hard-coded rule such as “Any live cell with fewer than two live neighbours dies” also states the spirit of the rule: “as if caused by under-population”. Aha! We should write our code in terms of under- and over-population instead of hard-coded boundaries.

My first pair after lunch, Anthony, used MacVim. I’m an old fan of Vim, but hadn’t seen MacVim. We talked about the fact that the grid is infinite, and decided to see if we could get information about the neighbors of any one cell, working with relative numbers. Anthony was pretty sharp at figuring out how to do this, and we made a lot of progress in the 45 minutes. Other pairs tried starting with the outside abstraction and working in.

I was getting tired and didn’t take as many notes in the afternoon – it was all I could do to keep up with what my pair was doing. I had low expectations with regard to my Ruby coding knowledge, but I learned how much I don’t know! For the last session, I was the kid who didn’t get picked for the softball team, I didn’t have a pair, so I observed Rob Park and his pair working in Java. I work on a Java team. It was interesting to see the immediate contrast of working in Ruby vs. Java for the same coding problems. Java looked much slower and more cumbersome to me.

We finished with a closing circle where each person stated what we learned, what surprised us, and what we’ll do differently back at work on Monday. Many of the participants were new to pairing and TDD. I’m not, but it reinforced the value I’ve gotten by learning through pairing with a programmer. I learn more about code design in an hour of pairing than from days of reading books. I plan to be more diligent in applying good design principles to automated test code – for example, pay more attention to using good names. I won’t just take the first solution that occurs to me, I’ll experiment with different approaches. Let’s see if I achieve that goal!

I’m doing two tutorials (including one together with Janet Gregory) and a track session at StarEast 2011 (see my News and Events page for more details or click to see the brochure). If you use the discount code SKWS you can get $200 off, and if you book before March 4 you also get Early Bird pricing which is another $400 off. Take a look at the program, there will be a lot of great practitioners there this year. Not only are there some valuable sessions, you’ll learn a lot from the informal activities with fellow participants.

When I read Earl Everett’s foreword to Managing Software Debt: Building for Inevitable Change, I knew I wanted to keep reading. He points out that “system architecture is a human activity”, and that Agile recognizes the humanness of systems development. That’s my experience, and this book affirmed that delivering valuable software frequently and consistently over the long term requires having the right people and letting them do their best work. In Chapter 8, the author references Gerald Weinberg’s “Second Law of Consulting”: “No matter what the problem is, it’s always a people problem”. When this sentiment runs through a book, it resonates with me. Also – I can’t resist a book in which each chapter starts with a mind map! (Hmmm, where have I seen that before? ;-> )

My copy (the old-fashioned print kind) bristles with Post-It tabs marking so many terrific observations. The author advocates a whole team approach to development, where testers, programmers and other roles work together. One statement I especially like: “Everyone on the team should be able to execute any and all automated and manual test cases.” (p. 59) Amen!

I appreciate the graphics illustrating how software debt impacts applications over time, such as the downside of “like-to-like” migrations where organizations think they can simply do a new project to replace their system with a better solution. The book makes excellent use of graphs, illustrations, whiteboard drawings, and code examples to clarify various techniques that reduce debt and promote quality.

The first step in paying back technical debt is to acknowledge that it exists. The author points out that “No matter what, the cost of addressing technical debt increases with time”. In my experience, teams often say that their management won’t approve their working on the technical debt, when in fact, if the business executives such as the CFO understood the cost, they’d prioritize it over new features. In this book, you will learn how to quantify the cost of the debt and the return on paying it back, and how to help your customers understand it. As the author notes, the customer expects the team to know how best to develop the software they need. Graphs illustrate how much the cost of technical debt increase over time. We’d be irresponsible if we failed to educate our customers about this.

The book presents different techniques for cleaning up software debt, supported with code examples where appropriate. More importantly in my view, the reader will learn approaches that enable teams to sustain internal quality, including sustainable pace, collaboration, refactoring, small batches of work, and more. It goes on to explain these approaches in detail, again with examples and illustrations to make them clear.

The chapter on quality debt looks at reasons why teams don’t automate regression tests, both functional and extra-functional, and shows how this leads to ever-lengthening regression test execution time. The author points out the drawbacks of having multiple queues of work, including a defect tracking system, and gives several alternatives for overcoming these issues. I like the emphasis on correct test design when using ATDD to address quality debt.

The only issue I had with the book was minor. I really liked the section on tracking issues collaboratively, but it seemed out of place in the release management chapter.

One great technique I learned from the book that was new to me is “abuse stories”. Your customers might not prioritize a story that says “Implement security for payment information”, but this story might get their attention: “As a malicious hacker, I want to steal credit card information so I can make fraudulent charges”. I’d love to participate in an abuse story writing session now that I know how!

In my experience, an organization’s culture is more important than any technique or practice. The author points out that teams need to learn the skills and knowledge to address evolving product requirements, and they need time to do this. He then explains various ways to create knowledge and apply it to the product, and how to budget for this. Now, don’t roll your eyes and say “our customers will never allow us to take this time” if you haven’t explained the technical risks of not doing a technology evaluation. This book will help you work with the customer to identify technical unknowns while making progress toward providing new features.

The book addresses the interesting issue of extreme specialization. The author suggests that we should give projects to cross-functional teams instead of creating teams to work on projects, which enhances learning and avoids knowledge silos. I was especially pleased to read the section in Chapter 11 on personal development, with examples of how various teams make time for individual and team learning.

I wished the book had more of a “big finish”, but I like the concluding paragraph, which starts: “Investing in people is probably the most effective way to create sustainable software”. (p. 220). That’s congruent with my own experience. Many of the topics in this book have been covered in other books, but here you will see them in a new perspective. We want to deliver business value frequently, year after year, while working at a sustainable pace and enjoying ourselves. If that is not happening where you work, this book will help you reverse the trend.

I’ve been wanting to try Weekend Testing for ages, but I’m usually swamped on the weekends. The European chapter that does Weeknight Testing (@WNTesting on Twitter; hashtag #WNTesting) works great for me because the time ends up being during my lunchtime. I tried it for the first time today.

Our mission was to do functional testing on TinyURL. The plan was to test for an hour, then debrief & discuss. I paired with Darren McMillan and we started working on a mind map in MindMeister. At the same time, I was trying things and noting it down in TextWrangler. We tried happy path tests, negative tests, boundary tests, crazy urls, trying in different browsers. I tried out features such as custom URLs and preview, both of which were not as intuitive as I hoped but this was meant to be functional testing.  Darren had ideas I didn’t think of, such as URLs with accents on the letters.

The debrief was interesting, other people thought of such good approaches. One thing I hadn’t thought of was urls in other character sets. Things like turning Javascript on and off did not even occur to me. People used tools and heuristics that were new to me. This was fun, and a super way to get ideas for good ways to do exploratory testing. I intend to keep on joining Weeknight and Weekend tester sessions as often as possible!

Here is a scaled-down picture of our mind map, you can click on the link higher up to get the full version.

Mind Map for Weeknight Testing Session

I am honored that Agile Testing: A Practical Guide for Testers and Agile Teams by me and Janet Gregory is on Jonas Bandi’s list of his favorite software development books of 2010, especially because the other books in the list are also some of my favorites for the year. The start of a new year is a good time to set learning goals, and this list of books would make a great place to start.

I was so pleased when my copy of Naomi Karten’s Presentation Skills for Technical Professionals arrived the day before I left for Agile Testing Days in Berlin. I started presenting at conferences in the late 80s, and have presented at many conferences in this millenium. I’ve worked hard to improve as a speaker, facilitator and coach, I’ve taken lots of public speaking and presenting classes, I study the evaluations from each session’s participants, I read blog posts about how to present. But behind my conference persona, I am an extremely shy person, so it’s always a fight.

I read Naomi’s book on the flight to Berlin. It’s an easy and entertaining read, and I learned a lot. One gem was the advice to pause occasionally – when finishing a key point, when inviting questions, before advancing to the next slide. It gives participants time to let the information sink in, and to formulate questions. I talk WAY too fast, so this was a good tip for me. I remembered many times during my Agile Testing Days tutorial and keynote to pause for a moment, and that helped me remember to speak more slowly and clearly. (I still got evaluations that said I was hard to understand, but I hope I was better than in the past).

Another important takeaway was to set up ground rules at the beginning of the session. I always do this, but I liked the suggestion for managing time, to say to the group, “If we’re running short on time, would it be alright if I discontinue some discussions in the interest of moving on?” By framing a ground rule as a question, you get buy-in from the group.

Building rapport with the audience before the session starts was another good tip. I’ve done this in the past, but because I am such an introvert, I didn’t do it enough. I made a conscious effort in Berlin to engage individuals who arrived early and ask about their experiences on the topic I was about to present. When I got nervous later, I could look at the people I’d talked to ahead of time and felt I was in the company of friendly people.

The chapters on logistical preparations and the “presenter survival kit” contained many good reminders of things I know, but sometimes get sloppy about. For example, I had gotten out of the habit of putting my slides on a USB flash drive, in the event my MacBook dies and I have to borrow a laptop. I always think “I can download it if I need it”, but many conference rooms don’t have internet connectivity.

I think I’m good about avoiding PowerPoint abuse – my slides aren’t flashy, but they are also not overcrowded with information, and I don’t read them – but the chapter on using (and not mis-using) Powerpoint has good pointers (no pun intended). I also tell a lot of stories, so I was glad to read that Naomi recommends this practice and explains how to craft a story.

There is lots more great information about all aspects of presenting in this book. I highly recommend it to everyone who ever has to make a presentation – whether you only rarely have to present to fellow employees, or speak frequently at conferences. It has good reminders for experienced speakers, plus some nuggets you might not have thought of. If you’re new to presenting or nervous about it, following the instructions in this book will give you much more confidence and let you enjoy the experience instead of dreading it.

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.

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.