Home > Articles > Programming

My Life in Tech: Q&A with Agile Testing Coach Lisa Crispin

  • Print
  • + Share This
Lisa Crispin talks about starting her programming career with no experience, how the role of testing has evolved over her 30+ year career, and how software teams are like donkeys.
Like this article? We recommend

InformIT: You have worked in the tech industry for more than 30 years. What got you started? What kept you going?

Lisa Crispin: I had been laid off during a recession, with an MBA and two years’ experience coordinating research for a government agency. I wanted to move to Austin, Texas. I went to the University of Texas employment office, and spotted a sign: “Computer Programmer Trainee, No Experience Necessary.” Well, I had no experience, so that sounded good! I was given an aptitude test, which apparently I aced. They interviewed me and hired me the same day.

U.T.’s Data Processing Division had a great idea back in the early 80s. They hired people who didn’t know how to code (that was easy, back then!) and trained everyone on the job. We all learned to write code exactly the same way, so collective code ownership was easy! The most recent crop of trainees trained the brand new trainees. The managers knew they could train anyone to write code, so instead, they hired for domain knowledge. It was brilliant. And there were just as many women programmer-analysts in our department as men.

I’ve been fortunate to keep learning new technologies that helped me get jobs on great teams over the years. In the beginning, I thought “I’ll work in software until I figure out what I really want to do in life.” One day, I realized that I was already doing what I love!

InformIT: Did you have any particular role models in the programming/testing field  – someone you looked at and thought, “I want to do what that person is doing”? 

Lisa: Right from the start I worked with people who inspired me and gave me good advice. I didn’t know anyone in the bigger software world, but I was lucky in my first several jobs to work with terrific people. I took a job in the early 90s with a database software company. The VP of Engineering and several of the managers were women. Same situation when I joined my first web startup in 1998. I admired them and tried to learn from them.

That was also about the time I went to my first testing conference and started reading magazines such as what is now Better Software. Through these channels I later learned about people such as Brian Marick and Elisabeth Hendrickson, who were big influences. I met Linda Rising and Mary Lynn Manns when they were writing Fearless Change, and not only have I made good use of their patterns for introducing change, but they continue to inspire me.

When I started on my first XP team in 2000, I was amazed to find the leaders of the XP community to be quite accessible. When taking a course from Bob Martin, I asked so many questions about acceptance testing that he gave me Ward Cunningham’s number and told me to call him. I did, and Ward spent an hour explaining testing in XP to me! Kent Beck spent an afternoon at a conference answering my questions. Over the years, these leaders have continued to be encouraging and helpful to me, and they urged me to write my first book, Testing Extreme Programming, with Tip House in 2001.

InformIT: You co-wrote your book, Agile Testing: A Practical Guide for Testers and Agile Teams, with Janet Gregory in part because you maintained that much of a tester’s function was largely misunderstood. Is that still an issue? How has the role of testing evolved since your book was published in 2008?

Lisa: As agile has been more and more widely adopted, there are always teams and development organizations that don’t understand how to “bake quality in” to a product, and they don’t know how good testers can contribute to that. At the same time, we’ve seen agile teams realize they need to not only drive development with examples and tests, but also critique the product through exploratory testing and technology-oriented testing such as security and performance.

Since we wrote our book, the lines between different roles on a team have continued to blur. Coders do lots of testing. Some testers do lots of coding. We have realized we may need lots of other types of expertise on teams, such as business analysts, UX designers, DevOps. We’ve found help in unexpected places, learning much from other areas, such as marketing and sales, about what our customers need.

The testing profession has really expanded and evolved. Just look how many testing conferences are held around the world today. And it’s global. There are innovative and vibrant testing communities everywhere – The UK, Europe, India, the Pacific Rim. And we’re united by global online testing communities such as Weekend Testers.

Unfortunately, in my opinion, most executives still don’t understand why their company needs testers, and more fundamentally, why they should focus on quality rather than speed. We have to try to find ways to educate them.

InformIT: What sets agile testing apart from other kinds of testing?

Lisa: Agile testing is simply testing on agile teams. What makes a team agile? I like Elisabeth Hendrickson’s Agile Acid Test, which goes something like this: An agile team delivers value frequently (at least once a month) to production, while maintaining a sustainable pace. The key is “sustainable pace” – to do this successfully over the long term, you have to master core development practices that keep technical debt to a manageable level, such as TDD, ATDD, CI, and work to continually improve.

InformIT: What’s the toughest part of being a software tester?

Lisa: I find it hard when the programmers treat testing as a separate activity, and the testers as a separate team. As Elisabeth says, testing isn’t a phase. We should be working together throughout. If you’re a tester on a team that’s not used to having testers as part of their development team, it can be difficult to show them how you can add value, and to get them to help you when you need their expertise. It takes a village to create a great software product.

InformIT: What advice would you have for those who want to follow in your footsteps?

Lisa: Keep your own life, especially your day job, at a sustainable pace, and budget time to learn. To succeed as a tester, you need T-shaped skills. Some of these will be broad and more shallow, such as a high-level understanding of the architecture of the system you test, basic coding concepts and design patterns, ability to use an IDE and source code control. Some will be your own deep specialty, which could be domain knowledge, exploratory testing skill, or expertise at designing automated tests. As with anything, you need time to build all these.

Aspire to magnificence. This requires you to spend some of your personal time learning. But if you love your work, why wouldn’t you practice it in your non-work hours? Just as a concert pianist must practice in order to perform well, we have to spend some time practicing both at work and at home. Join online testing communities, participate in Weekend Testers, go to a Code Retreat, or hold a testing dojo. Hone your craft, but also take time to stoke your creative fires.

InformIT: What are you most proud of doing in your 30+ year career?

Lisa: Being part of a team for more than eight years that created a highly valuable product for our company and our customers. We achieved many things that others said weren’t possible. And we kept pushing ourselves to do even better. We were true participants in the business, not “that engineering team over there.”

I’m also proud of overcoming my shyness to be able to share our lessons learned with others, so they could use what we learned to create their own small experiments to try. Gathering experiences of ourselves and others, and sharing those in books, is hard yet rewarding work.

InformIT: What would you do differently?

Lisa: Hard to second-guess. There was a time I regretted leaving a high-paying job where I’d have made a huge amount of money. I had done that so I could join my first Extreme Programming team. But in the long run, though it took quite a few years to get back where I’d been financially, I was much happier.

InformIT: What is the funniest thing a developer has ever said to you as a tester?

Lisa: “You’re seeing that problem because you have too many windows open.”

InformIT: What is the biggest mistake a tester can make when working with an agile development team?
Lisa: Not realizing that you have to earn your credibility and show how you can add value. You don’t add value by focusing on picky little problems or by keeping yourself in a silo. You have to find ways to reach out to the other team members, ask them to solve testing problems together, and learn how to speak their language.

InformIT: What is the most important skill that a tester should have?

Lisa: I don’t know if I can identify the most important one. Maybe the desire to learn?

InformIT: In addition to being a tester yourself and a writer, you also do some coaching and tutorials. How do you find the time for all of your work?

Lisa: And besides all that, I drive my miniature donkeys and ride horses! One key is that for most of my career, I’ve worked on teams that work at a sustainable pace. If you work 40 hours a week, there is time left over for professional development outside of work. I started writing and presenting to help with my own learning. If I have a session at a conference, I get to go to the conference for free and enjoy many great sessions facilitated by other presenters! And I find that writing, even blogging about an interesting experience at work, helps me learn more from my daily activities.

I’m also lucky to be married to a very supportive person, who does more than his share of taking care of our place and our animals so I have time to write.

InformIT: In your field, what do you think is the most exciting thing going on right now?

Lisa: I’m gratified that functional test tools finally “grew up,” and we have frameworks and tools that are just as good as for unit testing and also part of the integrated development environment. Now that many teams have good automated regression test coverage, they have time to devote to other critical testing activities such as exploratory, security and performance testing. “Testing in production” is an exciting new approach for software-as-a-service products with large numbers of users. And we have big challenges such as testing mobile applications on an ever-growing number of devices. Best of all, programmers, analysts and other roles on teams are just as interested in these challenges as testers. It’s a great time to be a tester!

InformIT: You mention on your website that you’ve spent your whole life training horses and donkeys. How has that experience helped you in your career?

Lisa: Well, for one thing, it’s a great way to shed off any stress from the day’s work. When you get on a horse, if you aren’t fully in the moment, you won’t be able to partner effectively with your horse. When I started training my donkeys, I discovered they’re quite different from horses. There are different ways to motivate a horse to do what you want. But a donkey won’t cooperate unless it trusts you completely.  Once you earn that trust, it’ll do anything you ask. Over the years, I learned the value of trust on a software team. When I worked with the same people for several years, we could have productive discussions about that tricky design decision, because we knew disagreements weren’t personal.

Lately I’ve realized that when my donkeys and I improve our performance together, we have a stronger bond and enjoy ourselves more. This is true of software teams too!

  • + Share This
  • 🔖 Save To Your Account