Five Testing Questions with Lisa Crispin

I want to start this “Five Testing Questions” interview with a personal story:

It was about 4 years ago, as I started doing testing consulting, I began running into work opportunities where companies were looking for help in implementing Agile Testing as part of Agile Development efforts.  I knew about Agile mostly from what I read on posts or discussions in the web, but I had no real Agile experience.  And so I began by reading as much as I could on the topic.

I found a lot of people commenting about how testing was lagging behind on the Agile school of though, and others going as far as saying that in the Agile world testing was bound to be extinct as a profession (sounds familiar even today, right?).

But the first and most complete piece of information that actually explained how to work and provide real value as a tester in an Agile development team came from a book released that year (2009) writen by Lisa Crispin and Janete Gregory simply and accurately called “Agile Testing“.

This book was extremely helpful to me as a testing consultant and a test manager in a number of Agile teams.  It  explained how Agile testing is not very different from the testing we’ve been doing all along, but how the holistic approach to testing in the complete development team needs to be “a little” different in order to succeed.  And how these “little differences” need to be pushed and lead by the testers in the team.

The interesting fact about their “testing book” is that I started seeing it and being cited by many development leads and R&D managers, not only when they talked to their testers but also when they communicated with their whole development team.

So in short Lisa, I wanted to personally thank you (and Janet) for the help you gave me while starting my path in the world of Agile testing.  And also to thank you on behalf of all the readers, tester and programmers, who today understand the concept of Agile testing better because of your work.

About Lisa

To quote her personal site “Lisa Crispin is an agile testing coach and practitioner”.  You can find her talking and contributing in many Agile Testing conference and forums.

She has worked in IT for a number of years not only as a tester (QA Manager, Director, etc) but also as a programmer, analyst, support engineer, etc.  Maybe helping to support the theory that the best QA engineers actually come from a well rounded technical background and experience, helping them to provide value to the whole organization (read more on her answer to the first question bellow).

A thing that I always find interesting when reading Lisa’s posts or her twitter feed, is her work with donkeys – I guess people need to have non-technical occupations in order to continuously feed their technical minds 🙂

And without much additional introduction, let’s move to Lisa’s very interesting answers to my 5 testing questions…

Five Testing Questions

1) What is the role of testing in today’s “typical” development process or organization?

Hmmm, it’s hard for me to say what is “typical”. I still see many dysfunctional development organizations around, where no value is placed on quality, and teams labor under ever-increasing burdens of technical debt. Often, in those types of companies, testers are undervalued, and often, the people hired as testers lack skills and don’t have any passion for testing and quality, which reinforces the view that testers are some kind of second-class team member.

The role of testing should be, IMO, an integral part of development, along with coding and other activities needed to create a quality software product. As Elisabeth Hendrickson says, testing isn’t a “phase”. The successful teams I’ve been on – whether waterfall or agile – start each new feature by writing tests. They continue to test, code, test some more in small increments and iterations until they have something of value to release. There are definitely testing activities that still need to happen once coding is thought to be complete, such as exploratory testing, so that we learn what else may still be needed in the feature or set of features.

I know many testers nowadays who play an integral part in helping business stakeholders decide on the features that provide the necessary value, get examples to illustrate desired behavior, and turn those examples into tests that help guide development. These testers collaborate with all roles on the development team to deliver valuable features frequently, while keeping technical debt to a manageable level so the team maintains a steady cadence.

2) Which are the most important traits a tester should have (or should develop) in order to succeed today?

Attitude is everything. Curiosity, a passion for learning, willingness to take on any task, desire to collaborate with team members and customers in other roles, courage to experiment. The skills needed to make all that happen can be learned.

Of course, the ability to learn requires that the company nurtures a learning culture and ensures “slack” time for learning, experimenting, innovating, failing, improving.

3) There have been a number of publications, talks and twitter threads lately about the possibility that testing is in fact a “Dying Profession”.  Do you agree with this statement?

Janet Gregory and I recently refuted the “Testing is Dead” myth in our keynote at Agile Testing Days. Development teams should examine their environment and their team cultures.  Some teams may not need a professional “tester”. I have met teams whose developers had enough testing expertise and were able to produce quality software without any team members in a testing role. However, these tend to be teams working on highly technical solutions, such as message handling systems or other types of embedded software, whose customers are other development teams. What I’ve seen though, is that these teams tend to be working on more technical solutions.

As soon as a system has business users and the domain knowledge is critical, the “no testers needed” model tends to fall apart. Teams need someone who can focus on the bigger picture, and ask questions to reveal hidden assumptions. It’s hard for a programmers to keep up with the technical knowledge needed to program really well, and focus on one tiny part of the system that they’re currently coding, and be thinking about the bigger picture as well.  In my experience, testers think of questions that don’t occur to programmers. For example, a business stakeholder may assume the development team will provide adequate security for an application, while the programmers focus on the functionality that the customers want and don’t even think about security.

The testing profession is changing fast, but I’m confident that we’ll always find ways to contribute significant value.

4) Looking back at your successful professional career, can you point to 2 or 3 milestones (or people) that made you the testing professional you are today?

My second manager, back when I was a baby programmer, taught me something important about leadership that has guided my career. He said leadership means helping others understand the value that you and your team contribute. We need to make our contributions visible. Lots of people, especially women, feel this is “tooting your own horn” or bragging. But it’s especially important in a culture where testing, and testers, have often been under-valued.  Throughout my career, I’ve helped managers and other teams understand the risks involved in a given project, and what we can do to not only mitigate those risks, but deliver a really great product that delights our customers.

Another big milestone for me was learning about Extreme Programming. In the 90s I worked on a great waterfall team that had complete automated test coverage from the unit level on up, continuous integration, automated deployment, and took time to do enough exploratory testing. The waterfall methodology was fine, because we worked on a database product that only needed to be released once a year. When I moved to a web startup, suddenly that waterfall process didn’t work anymore. What was worse, everyone was in such a rush to get software out the door that they ignored good practices and just hacked out solutions

In 2000, one of my friends went off to form their own startup, and they gave me a copy of Kent Beck’s Extreme Programming Explained.  Reading it was an epiphany. It was all focused on quality, and collaborating with the customers! I had to try it. I begged my friends to hire me as a tester, and never looked back. The Whole Team Approach to quality is exactly right for me.

5) What would be your most important piece of advice to a beginner tester today?

Learn. Be courageous. Ask for help. Try experiments. Ask your teammates to pair with you, whether they’re other testers, programmers, customers, analysts, database experts, whatever. Pairing is the fastest way to learn.

Take advantage of all the free resources today: ebooks, blogs, webinars, videos from conferences, online courses. Join your local testing user group, or if you don’t have one, start one! Or, start a testing Community of Practice within your own company. We need a place to share experiences and ideas. Start up a Lean Coffee group. Join Weekend Testing sessions to learn from testers all around the globe. Join the Software Testing Club to tap into a similar global testing community.

Learn by doing. Blog about your experiences. Present at a local user group or a conference. Go to a code retreat. Work through a book such as Everyday Scripting with Ruby by Brian Marick to learn a scripting language. I’m often asked if programming skills are required to be a tester on an agile team. You don’t need to be a programmer, but you should be what Janet Gregory calls “technically aware”.  At the same time, you must also invest time to learn your company’s business domain, so you can help your customers solve their problems. You need to be able to communicate with everyone on your development team, and with your business stakeholders.

That sounds like more than one thing, but I think the focus should be: “Learn!”

Thanks to Lisa!

Other than the personal thanks I gave her at the beginning of this post for her contribution to my agile testing career, I wanted to thank her for the insightful and complete answers she provided to my five questions above.

I found specially true her advice to “Learn. Be courageous. Ask for help. Try experiments…”  These are the things that will really make a difference for most testers in the long run (as opposed to finding one or ten additional bugs in our current testing project).

Hand in hand with her self-description of being a “testing coach”, I think that many testers will find in these answer tons of useful knowledge and ideas on how to continue improving and expanding our test careers.

If any of you has feedback for Lisa and her answers feel free to leave them as comments and I will make sure they reach her.

More to come…

I am already working on the next Five Testing Questions interview, but if any of you has ideas on additional testing experts and personalities you’d like me to interview feel free to let me know by sending me an email or leaving a comment.

, ,

  • Dani Almog

    Joal – thanks for the opertunity to expose Lisa and Janet and thair contrubtiion to our testing world.

  • XtinaS

    Your link goes nowhere. Also, “fist”. Editors: QA folk for writing!

  • joelmonte

    Thanks for the feedback, even qa-guys can have bugs sometimes 🙂

  • Pingback: | Качество программного обеспечения()

  • IAmATester

    Interesting. Lisa Crispin is a complete and utter hack. It goes with the old adage, “Those that can, do. Those that can’t, teach.” Having seen some of the tests that Lisa has developed is almost laughable. I have spoken with people who have worked with Lisa, and, in addition to being a difficult person to work with, has actually limited experience hands-on. From what I have been told, she is a Junior Tester, at best.

  • joelmonte


    I just took out a comment that talked in an unflattering way towards Lisa Crispin’s work as a tester. I took it out not because I don’t believe in open criticism and dialogues (as log as it is concrete and productive!), but because the blog was posted in an anonymous way.