Interview with Lisa Crispin: whole-team approach to quality

Lisa Crispin is an agile testing practitioner and consultant, co-author of two books.  In 2012 Lisa was voted as the Most Influential Agile Testing Professional Person, an award program sponsored by the Agile Testing Days conference.

Hi Lisa, can you please tell us about yourself, your current occupation and expertise?

I’ve been a tester on agile teams since 2000. I started out my career as a programmer/analyst, and I got interested in testing in the early 90s. Currently I’m a tester on the Pivotal Tracker Team, our product is an agile project tracking tool.

My recent experience in the domain of software testing outsourcing is testing SaaS products, both from a UI and API perspective, and I’ve done a bit of testing on our iOS product as well.

I like to share my experiences with others and learn new ideas, so I do a lot of writing and presenting at conferences. Janet Gregory and I have published two books: Agile Testing: A Practical Guide for Testers and Teams, and More Agile Testing: Learning Journeys for the Whole Team.

A large number of organizations are currently moving from traditional cycle to agile development. How will this process influence testing?

To succeed with delivering valuable software over the long term, the whole team must take responsibility for quality, planning and executing testing activities. Our mindset has to shift from finding bugs after coding to preventing bugs from occurring in the first place. That means that testers, programmers, designers, product experts, database experts, operations experts, everyone has to collaborate continuously. We have to think about testing even before we think about coding.

What are the main characteristics of testing on agile projects?

A whole-team approach to quality, test-obsessed developers, guiding development with testing both at the unit and acceptance test level, getting a shared understanding of the product and each new feature before we start testing and coding.

Since we’re doing TDD (test-driven development) and ATDD/BDD/SBE (see below for definitions), agile teams have fully automated regression testing, leaving plenty of time for testing practitioners to do the vital exploratory testing so that we learn as much as possible about our software. For these approaches to succeed, the team needs a culture that supports learning and experimentation. You can’t focus on delivering software fast – you have to focus on delivering the best possible quality software.

What skills should a tester have for testing in agile?

Curiosity, a love of learning, an agile mindset, an attitude of “I’ll do whatever is needed to help”, technical awareness, the ability to communicate and collaborate with customer and technical team members.

Can you give some examples of testing approaches on agile projects?

Successful agile projects typically use some form of guiding development with customer-facing tests, whether it’s behavior-driven development (BDD), acceptance test-driven development (ATDD), or specification by example (SBE). Those are all similar. We start by getting the whole team together to talk about a new product or release, identify the backbone or “walking skeleton”, and thinking about how we’ll test it.

We use techniques like personas and story mapping (as in Jeff Patton’s terrific book) to build shared understanding and identify thin end-to-end slices of value. We get product experts, testers, developers, designers and others as needed to have conversations about each user story, specify rules and examples of desired behavior with techniques such as Matt Wynne’s example mapping. Developers code test-first, both at the unit and acceptance level. They may do exploratory testing of each story before they finish. Testing experts do exploratory testing at a feature level. They help the team discuss all the different quality attributes, both functional and non-functional, and make sure appropriate testing activities are done.

What tools are commonly used for testing in agile?

If you mean automation frameworks, libraries and drivers, teams should first decide how they want their tests to look, and then identify a tool that supports that vision.

Test automation is vital, to free up time for exploratory testing. But conversations and collaboration are far more important than tools.

Automating regression tests is generally a must, but we need more. We need to start with a shared understanding of each new product, release, feature and story. As I mentioned, story mapping is a helpful technique. We need both testing and business analysis skills. We need to explore the code before and after it is delivered to learn whether it really solves problems for customers.

How testing can be completed in short iterations?

The whole team takes responsibility for testing, and includes testing activities when planning each feature and story. No story is done until it’s tested. TDD and BDD/ATDD/SBE help accomplish this goal. Close collaboration between testing experts and development team members helps make sure testing doesn’t lag behind.

A common problem with new agile teams is “over-committing”. They’re so keen to please their customers; they plan too many stories in iteration. To avoid disappointing their customer, they skip or put off testing activities. Instead, teams should plan to do less work, but do it as well as they possibly can. When you build a strong code and test base by focusing on quality, you’ll be able to deliver faster in the future.

Try a “lean” approach where you limit the number of stories being worked on at any given time, focus on finishing one story at a time and then moving on to the next.

What are the main principles of an agile tester?

Janet and I devote an entire chapter to this in Agile Testing. Here are our 10 principles for an agile tester:

• Provide continuous feedback.
• Deliver value to the customer.
• Enable face-to-face communication.
• Have courage.
• Keep it simple.
• Practice continuous improvement.
• Respond to change.
• Self-organize.
• Focus on people.

What documentation is necessary on agile projects?

You need the documentation you need. The Agile Manifesto values working software over documentation, but we still value documentation. Janet and I find that automated regression tests created as a result of BDD/ATDD/SBE provide excellent living documentation of how the system behaves.

The tests always have to pass, so they must be kept up to date. But you may need additional documentation for users, regulatory agencies, team memory. Each team should decide what is needed. Talk this over with your business experts and auditors too.

How is it possible to create appropriate documentation?

Using executable acceptance tests as mentioned in the last question are one terrific way to create documentation. You can even generate documentation. My team generates our API documentation, including examples that are from actual tests.

In my experience, most teams need to hire a good technical writer to help create useful, long-lived documentation.

What can you recommend to agile testers?

Keep learning. There are plenty of online resources and communities where you can learn and practice new ideas and skills. There are so many great testing conferences these days. Read, practice, experiment!

What do you think future will bring to agile?

I don’t try to predict future, but, it’s still my experience that it is difficult to find a tester with the right attitude and mindset to contribute to an agile team. At the same time, more and more delivery teams realize the importance of testing activities such as exploratory testing and BDD/ATDD/SBE. Some teams, including my own, are adapting by hiring the few top-notch testers who can transfer their testing skills to the developers on the team.

Testing activities are done by everyone on the team. This doesn’t mean we don’t need testers, but it does mean we need testers who are good at helping their teammates learn good testing skills.

Thank you, Lisa, for devoting your time and sharing your thoughts with us. Hope to talk to you again.

To learn more interesting things about Lisa Crispin visit her website.