Interview With Lisa Crispin
Lisa Crispin is the co-author, with Janet Gregory, of three books: Agile Testing Condensed: A Brief Introduction, More Agile Testing: Learning Journeys for the Whole Team, Agile Testing: A Practical Guide for Testers and Agile Teams; the LiveLessons Agile Testing Essentials video course.
She and Janet co-founded the Agile Testing Fellowship, which offers “Holistic Testing: Strategies for agile teams” live training course both remotely and in-person. Lisa was voted by her peers as the Most Influential Agile Testing Professional Person at Agile Testing Days in 2012.
She is the co-founder, with Janet, of Agile Testing Fellowship, Inc. and is available to do training and consulting. Please visit www.lisacrispin.com, www.agiletestingfellow.com, and www.agiletester.ca for more.
For the uninitiated what exactly is agile testing? Can you think of an instance/ context where it would NOT be appropriate?
Janet and I worked with several people in the testing community to come up with our own definition of agile testing a few years back, we blogged about it.
The short definition was:
*Collaborative testing practices that occur continuously, from inception to delivery and beyond, supporting frequent delivery of value for our customers.
Testing activities focus on building quality into the product, using fast feedback loops to validate our understanding. The practices strengthen and support the idea of whole team responsibility for quality.*
I’ve personally been able to apply this approach even in organizations that had not successfully adopted agile, and that were pretty chaotic. As testers, we could help the development teams identify their biggest pain points, and suggest ways agile principles could help.
For example, when my dev team complained that either they got requirements so late, they didn’t have enough time to write the code, or they got no requirements at all, I suggested we try writing acceptance tests instead of requirements documents.
Even though the developers didn’t automate any tests, they still had a better understanding of what to build, and the lighter weight approach saved time.
That said, I think quality depends on some core development practices.
In today’s world, a team that is not practicing continuous integration and is not automating any tests is likely to fail in the long run. They can’t do enough manual regression testing to keep up, and they never will have time for key practices like exploratory testing.
Back in the day, I worked on a waterfall team where we only needed to release product changes every 6-12 months. Yet, the team automated unit tests to almost 100% coverage, we practiced continuous integration, we had automated deployments to two dozen test environments (different flavors of Unix), and automated tests at the UI level.
Everyone, including testers, developers, designers, and tech writers, participated in all the “phases” of waterfall development. We rarely had any critical bugs escape to production, and our customers were happy.
Good development practices, including testing practices, apply no matter what development process an organization chooses to use.
What’s the biggest misconception when it comes to agile testing?
Great question! One thing I see a lot is that agile teams will have a tester or two embedded on the team, yet, they still practice mini-waterfall. They hand off everything to the tester(s) to validate. They don’t embrace the whole-team approach, they don’t focus on bug prevention instead of bug detection. This doesn’t scale, one or two testers cannot keep up with the output of three, four, ten coders. Managers who are often ignorant about testing think they just need to hire more testers, and that is usually not the solution to quality problems.
I’m still often asked “what is the correct ratio of coders to testers?”
There’s no correct answer to this.
I’ve worked on high-performing agile teams where we needed as many or more testers as coders, even with the team practicing TDD, ATDD and everyone pitching in on testing tasks. The code wasn’t hard to write, but the business domain was quite high-risk - production failures could cause both customers and the company to lose money, or violate laws that would make the business fail. We had to be sure the product behaved perfectly.
I’ve worked on a product - a project tracking tool - where it was ok to have two or three testers for 30 programmers, because the programmers also used the product and understood it well, the risk was low (it’s inconvenient to have your online project tracking tool go down, but generally does not a huge financial loss or loss of life), and the team were expert at TDD, pair programming, exploratory testing, continuous integration, and automation.
As testers, we acted more as testing consultants and coaches, to help everyone learn the testing skills they needed.
Your book, Agile Testing came out 14 years ago. What was the testing landscape back when you and Janet Gregory wrote the book? And have you noticed a difference in how it was received back then, compared to now?
At the time we wrote our first book together, few software teams embraced the whole team approach to testing and quality. At the same time, new-to-agile teams struggled with fitting testing into short iterations, and testers joining their first agile teams were uncertain how to best contribute. So there was a big appetite for information.
We interviewed people all over the world, and learned that many teams encountered similar problems. And, they found similar ways to address those problems. The stories in our book resonated with our readers. This is still true today.
There are always people who are joining software teams for the first time, and there are still many teams transitioning to an agile or DevOps culture.
We are so delighted to continually hear from people, “Your book saved me when I didn’t know what to do” or “Our team relies on your Agile Testing book.”
I remember being a tad star struck when I met you at a conference. (I think it was Agile Testing Days 2018?) You are the co-author of one of the most recommended books in our industry, yet you attend talks etc - not just deliver your talks/workshops.
What have you recently learned in conferences that you have managed to apply or wanted to apply at work?
Aww, you are so nice to say that. I present at conferences (mostly interactive sessions) so that I can attend them for free! I love learning, and there are always new things to learn. I’ve always been keen about practices and tools on the right side of the DevOps loop.
Just one example, I remember attending a CitCon unconference back in 2008, where I picked up some great ideas to improve continuous integration that helped my team a lot.
Leading testing practitioners like Abby Bangser, Ashley Hunsberger, and Areti Panou inspired me to learn all I can about observability, testing in production, monitoring, continuous delivery, pipelines, and more.
I started attending DevOps and delivery conferences as well as testing-oriented ones. I’ve always been involved in what we now call DevOps, and have worked on a few teams that succeeded in adopting continuous delivery, so I can share my experiences in these areas as well.
You’ve recently gone independent. What are you most excited about with regards to this career move?
I’ve been lucky to work on several high-performing, self-organizing agile teams, and in effective DevOps cultures, over the past decades. I enjoyed working together with teammates to build a high-quality product and delight our customers.
Now, I want to share that experience more widely. I hope that through our Agile Testing Fellow training courses, workshops, and short-term consulting and coaching engagements, I can help more teams adopt good principles and practices that work well in their context. I am also excited about a more flexible schedule which means I can attend more online events so I can step up my own learning.
✍️ For more interviews, go here
📹 For my video interviews, go here
#Agile #Interviews #Testing