Agile Testing with Lisa Crispin
Providing Practical Agile Testing Guidance

I’ve spent my whole life riding and training horses. I was always generally happy with the job I did training my horses. But as in software development, thought leaders in horse behavior have discovered better training techniques. And just as I always strive to learn better ways to deliver magnificent software, I also work with expert horse and donkey trainers to hone my equine training skills.

Today, my donkey trainer, Tom, helped me with some issues I’ve had with my donkeys. He pointed out that as prey animals, donkeys don’t respond well to predator behavior. Say I’m leading Marsela, and she stops to eat some grass. If I also stop, move towards her, and jerk on the lead rope, I’m mimicking what a predator might do. That isn’t going to inspire a good reaction in my donkey.

It’s much more effective (as Tom demonstrated) to keep walking, but make it exceedingly uncomfortable while Marsela’s head is down in the grass. That way, deciding to not try to eat grass is her own idea. She can eat grass and be uncomfortable, or not eat grass and be left alone. My habit is so ingrained, I found it almost impossible to not stop and move towards my donkey. Yet, this does NOT work!MeAndMarsela2

In my experience, people developing software fall into the same trap. Here’s an example. I worked on a team whose managers talked a lot about agile, but where chaos still prevailed. I got an opportunity to apply agile principles to one critical project. The project was a complete success. I thought, hey, now we will get to try this on our normal development process! But a busy time period was upon us, and everyone panicked and reverted to the same old habits that didn’t work.

Falling into comfortable habits, even when they don’t deliver success, is apparently human nature. I suppose that’s why my sister can’t quit smoking. I don’t understand why we humans do this to ourselves. But every time my donkey puts her head down to eat and I stop, step towards her and jerk on the lead rope, I remember that this is NOT what will help my donkey walk willingly with me without grazing!

Nevertheless, I will keep practicing until the new habit of continuing to walk, while making it quite uncomfortable for the donkey to graze, and hopefully it will become my new habit. Same with software development – we have to practice new, more effective habits until they are second nature to us. Don’t beat yourself up for falling back into comfy old habits – but do keep pushing yourself to adopt the new, more successful ones.

You know how some topic will come up, and suddenly you notice it’s coming up over and over in different contexts? Lately, for me, that topic has been collaboration among roles on software teams.

My own team practices a “Whole Team” approach to development, and we testers work closely with the developers on a daily basis. Still, testing and support (all three of us testers do both) are, organizationally, a separate team with our own manager, who reports to the same director as the development manager. On top of that, our company didn’t even have testers before it hired the first tester on our team. Except for our team, which works exclusively on a software product, our company builds software for clients. The teams all do test-driven development, and automate tests all the way up to the GUI level. The clients’ testers help with acceptance testing. Testers have been hired on a contract basis, but not as permanent team members. So, there hasn’t been a culture of having testers, or really any people in different roles, on the project teams.

The developers on our team often express their appreciation for having testers on the team, we feel welcome. We generally collaborate well. And yet, there are impediments. Like all teams, we’re juggling many priorities. What’s important from our tester perspective might not match the top of the list for coding or for the product owner.

Jenga

Playing a game like Jenga is a fun way to get more comfortable collaborating. Everyone contributes to the tower falling over!

We continually think of experiments to work more closely with other roles on the team. For example, I got to pair with developers to write and automate customer-facing tests to drive development of our new API version. I found it hugely productive, but the team decided it was better overall to have me specify the tests on the wiki, and have the pair coding the story automate the functional tests. That’s why we experiment, to learn quickly what works best for the team.

More recently, we testers met with the designers on the team to brainstorm ways we could help each other. We now have some collaboration experiments underway that we think will improve the user experience while helping us think of more test scenarios.

I meet many testers who feel isolated from other roles on the team. They want more collaboration, but organizational or physical barriers get in the way. How can these testers find ways to work more closely with programmers, analysts, designers, business experts, and others? I think one component is finding better ways to share knowledge and help people learn so they can communicate. For example, testers with technical awareness, who know programming basics, understand their product’s architecture at a high level, and use an IDE and source code control daily, find programmers much more willing and able to communicate with them. As Rob Lambert has pointed out, these T-shaped skills help us overcome a phased approach to software development. Jesper Lindholt Ottosen recently suggested ways testers can organize and recognize our skills.

If you have testing problems you’d like to solve, think about who else besides the testers might be able to help you solve it. Though everyone gets involved in their own problems, you all have a common goal: deliver software that delights your customers. You’ll probably find that if you ask someone in another role for help that they’ll be eager to brainstorm possible solutions with you. At the same time, find ways you can help with other peoples’ problems, even if it means stepping outside of traditional “tester” activities. Pete Walen recently pointed out some non-traditional ways testers can understand business needs better. I personally think that blurring the boundaries between roles and bridging the gaps is the best way to advance the art and craft of testing.

I’d love to hear how other people have bridged the gap between different roles involved in producing software. Please add a comment here, or email me! Janet Gregory and I would love to have stories about this to include in our new book. Examples of how testers can collaborate with other roles will give those testers who feel isolated ideas they can try.

I hope this topic will come up in my “Advanced Topics in Agile Testing” workshop at Agile Testing Days. We’ll have a great group of people who will forge some new frontiers in testing!

 

Inspired by a discussion at TestBash 2.0 Lean Coffee, I find it useful to answer the question, “What are the last three things YOU did to improve”? See my article on Stickyminds.

Our team is working on an epic to provide some new features in both our product’s UI and our API. Today, I tested a delivered user story for the API. When I add things to our product via the API, I like to check them out in the UI. The basics of the story worked, but I was a bit confused by what I saw in the UI, so I walked over and asked a pair of programmers who were working on that epic.  “I expected to see X, but instead I see Y”.

One of the developers who’s done a lot of work on the epic explained the subtleties to me. He suggested a different scenario to try, and told me what he thought should happen. Bingo! When I tried his scenario, I found a couple of big ugly errors. We’d missed a corner of behavior, and it’s a big corner that will need to be fixed.

The behavior I had seen in the UI, that prompted me to go ask a question, turned out to be normal. But asking the question led me to find a big hole.

Don’t be afraid to ask questions. Even if what you’re seeing now is correct, your questions may lead you to uncover parts of the implementation that were missed or done incorrectly. Ideally, we’d think to ask these questions before coding is even done. But as happens all too often, I didn’t have the bandwidth to get involved in the planning of this feature so that I could ask the question earlier. Better late than never. Follow your curiosity, and be alert to your Spidey sense!

 

Spring is finally here in Colorado. We had a decent snowstorm on Tuesday, with temperatures well below 20 degrees F, but today it is sunny and shirtsleeve weather. I’m eating my lunch at my desk, but I’m going to go out and enjoy a walk along the Platte River in a few minutes.

I’ve had little time to write lately. I traveled a lot the first quarter of 2013, with a Hawaiian vacation, Belgium Testing Days, and a trip to England for TestBash 2.0 and some advanced agile testing workshops in Cambridge.

Dreyfus Model

Dreyfus Model of Skill Acquisition applied to evolving the Whole Team

This month I was lucky enough to be able to stay home for a great conference, Mile High Agile 2013. Here is a picture of the presentation that Matt Barcomb and I did on applying the Dreyfus Model to evolving the Whole Team – Matt wrote and drew the “slides” on the wall as we explained it! (And here are actual slides which are more readable if you weren’t there)

At the same time, we’re doing lots of home improvement projects, and when the weather’s nice enough, working the donkeys or going on walks with them.

And there’s my new job. In August, I joined Pivotal Labs to work on the Pivotal Tracker team. I’m on a “dream team” of testers including Marlena Compton and Jo Webb, we do support and testing along with the rest of our awesome development team. Elisabeth Hendrickson also recently joined Pivotal, though she works in a different area, doing magic with the cloud. Someone recently commented to me that we have a “Justice League” of testers here at Pivotal, and it is such a thrill to be part of that!

Though I was excited to get to work on the Tracker team, my first couple months were quite difficult for me. That’s just due to me and my ego, not my wonderful and helpful teammates. In the past, when I joined a new team, I always felt I brought something to the party. I had experience with agile and testing that the team lacked, so even without knowing the domain, I could contribute value right away. But the Tracker team already had agile and testing pretty much nailed. I hadn’t worked on a Rails project before, I hadn’t worked with Tracker before, I had so much to learn! And learning is fun, but I missed that end-of-day satisfaction of having contributed my share. I also worried that I’d never get up to speed, that I would fail.
Fortunately, lots of pairing helped me learn enough to start feeling like a worthwhile member of such a great team. My ping pong skills also helped. As with any job, there are still difficult days, but I look forward to coming to work every day.

All this learning, plus lots of personal life changes (e.g., moving to a horse property, losing my dad), took up all my time and mental bandwidth, and my writing output slowed to a trickle. However, I’m starting to slowly turn that around.

Having worked on a lot of distributed teams, that’s always a favorite topic of mine, and I recently wrote articles related to that for both SearchSoftwareQuality and Methods and Tools. In addition, Janet Gregory and I started working on our new book, with the working title More Agile Testing. I still haven’t found my writing groove. My longer commute means a lot of time away from home, and taking care of donkeys at home, though one of my favorite activities, does eat up the clock! But I’m livin’ the dream, and with enough practice, discipline and help from family and friends, I’ll find time to keep sharing my agile testing experiences and those of my team.

Happy spring!

 

While searching around for 2012 tax records, I found a file with printouts of the “Easter Egg” my team put into our website back in 1999. This Easter Egg was on the error screen. If you typed a particular search value, you’d get a page that looked like our standard error page, with the text:

“An error has occurred  — when asked about the problem, our developers would probably respond with:”

This was followed by an answer selected randomly from the following possibilities. These were from a list of things developers actually said to me, the tester, that were written on a whiteboard throughout the development of this product. (I wish I had a picture of the whiteboard! This was before everyone had a phone that’s also a camera!)

  • “I could just do it so it works”
  • “Have you been able to get anything to compile?”
  • “If you don’t think that it’s your fault, blame the tools”
  • “Hmm…. That’s bad”
  • “It’s working for me”
  • “We found out why the query page isn’t working…. there’s something weird going on”
  • “Who needs error checking?!”
  • “Just add more memory”
  • “I owe Steve $1,000,000 — Aaron”
  • “Never show your code your fear”
  • “Sweeeeeeeeeet!”
  • “Oh, it doesn’t compile? Just comment that part out.”
  • “In order to fix the bug, you must become the bug”

Ah, that brings back such fun memories. It was a great team. When I first joined them in ’98, the five developers (including one who was 16 years old – ah, the Internet boom years) they’d never worked with a tester. It was nice to develop a happy, collaborative relationship where we could kid each other and make lists of funny developer responses. I’d call them over to my workstation to see an error I got, and they’d say stuff like, “You have too many windows open!” I knew I’d proven my worth when one of them approached me shyly one day and said, “We’re going to come in this weekend to work on this project. Would you mind coming in to help us, so we know about the problems right away?”

What are your favorite Easter Eggs? What memories do they bring back for you?

I’ll be in Cambridge to do a workshop on advanced topics on March 19. Before the workshop, we’ll hold a Lean Coffee sponsored by Software East and open to everyone. Later that same day, I’ll be one of four speakers at the Software East meetup at RedGate software. Please join us at any and all of these events for fun discussions and networking!

And maybe the most fun: TestBash 2.0 in Brighton, March 22! Join me and a bunch of really cool speakers and participants. Please also consider supporting TestBash as a micro-sponsor. I’ll also be facilitating a Lean Coffee in the morning before the conference starts.LeanCoffee

For more information about Lean Coffee, see the LeanCoffee.org site. I facilitated Lean Coffees last fall at Oredev and Agile Testing Days. Pete Walen blogged about the AgileTD Lean Coffee. So did Chris George. Matt Heusser blogged about the Oredev Lean Coffee. I hope those reports motivate you to get up early after the Casino Night and join us!

At one of our Belgium Testing Days Lean Coffees, our topics ranged from Yahoo’s reversal on their working from home policy, to what to do about business stakeholders who won’t make decisions about features. This is a fast-paced event that will wake you up and get you ready for the day!

My friend Yves Hanoulle gently pointed out to me that I could do a better job providing information about the Lean Coffee at Belgium Testing Days by putting a bit of information online about it. So here goes!

7:15 a.m. – 8:15 a.m.  Friday, Satellite Room (go thru door across from where registration desk is, it’s down the hall on the left opposite the coffee break area).

Tea and coffee provided! LeanCoffee

For more information about Lean Coffee, see the LeanCoffee.org site. I facilitated Lean Coffees last fall at Oredev and Agile Testing Days. Pete Walen blogged about the AgileTD Lean Coffee. So did Chris George. Matt Heusser blogged about the Oredev Lean Coffee. I hope those reports motivate you to get up early after the Casino Night and join us!

This morning, our topics ranged from Yahoo’s reversal on their working from home policy, to what to do about business stakeholders who won’t make decisions about features. This is a fast-paced event that will wake you up and help you decide what sessions to attend at Belgium Testing Days!

Tonight I’ve been going through a lot of old papers and photos that belonged to my dad. He passed away a few months ago, having lived 89 years to the fullest. I take after him in that I have many passions and interests. He was quite the record-keeper, and neatly organized mementos of all of his different hobbies and interests. I’m not sure how he had time for all that, because he was also a busy and successful entrepreneur who ran his own businesses for 60+ years.

Looking back over a life like that, I can’t help pondering those “is that all there is?” type questions. Many a time I’ve asked myself in the past, “When you’re 90, will you look back and think, I’m so glad I worked late on that particular day, or will you remember the days at the beach?” Looking at my father’s life in the artifacts he kept, I think the answer for me will be like his must have been: all of the above.

I cram as much fun and enjoyment as I can into my life. And I’m fortunate that my work is also enjoyable and fun. I think I may treasure the memory of pairing with a smart, fun and energetic developer on my team today as much as I will a morning snorkeling in Kailua-Kona. OK, maybe in different ways, but I was fully engaged in both activities, learning, and really enjoying myself. Why wouldn’t I look back fondly at both work-related and personal activities a few decades from now? And isn’t that what it’s all about?

It’s really great to get an email from a customer who, thanks to my help, has been able to accomplish a goal. It’s nice to come across a card that former teammates gave me when I moved on to another opportunity, reminding me how much we all enjoyed working together. And, it’s great to sit on the couch in front of the wood stove with my cats and dog. We have to enjoy every minute of this life, and find rewards in both our professional and personal lives.

But as much as I’m enjoying sifting through my dad’s many boxes, I highly recommend NOT hanging on to quite so much STUFF! Nobody can take your memories away from you, and you don’t necessarily need quite so many reminders of them! That’s all from this evening’s philosopher’s corner.

Learning is good, whether in your career, or when you’re having fun! We tried standup paddle boarding last year in Oahu, and loved it, but we knew our technique was bad. In Kailua, the Hypr board rental folks gave us a really helpful lesson in SUP plus pointers on the second day. We paddle boarded 2 hours the first day and about an hour the second, and the practice paid off. I started to get the hang of it, I expended much less effort to move and turn the board, and I enjoyed it much more than if I hadn’t gotten expert help!

LisaRelaxSupIn this video, unfortunately I am not keeping my top arm straight, so I’m missing the “Triangle of Power”. Hmmm, it sounds a bit like the Power of Three in agile testing! Still, I’m practicing, doing my best, having a great time, enjoying amazing scenery. That’s what it’s all about, whether at work or play!