Lisa Crispin

It can be easy for testers to get into the mindset that they are the “Quality Police” solely in charge of when a product gets released. But when you share responsibility, ask questions, and talk to developers, customers, and stakeholders, you can really expand as a tester. Lisa Crispin details how collaboration has helped her grow.

Testing professionals who are learning about agile often want to know how they can provide traceability among automated tests, features, and bugs and report on their testing progress. Here, Lisa Crispin gives an example of how her previous team worked together to integrate testing with coding and helped everyone see testing progress at a glance.

The single largest retail event in the United States in 2014 may just be the Super Bowl. Selling those products—everything from hats to jerseys and foam fingers, too—means shipping logistics, websites, and, yes, a lot of software. In this article, Lisa Crispin and Lanette Creamer discuss how that software is tested; you might be shocked at what they found.

Lisa Crispin explains the concept of "group hugs," in which the whole team, or a subset of it, joins in for testing. Consider group hugs if you need to explore how your software behaves with concurrent users.

In this article, Lisa Crispin explains how impact mapping allows your team to generate multiple options to pursue. Be creative with your solution experiments. You won’t solve all your problems or achieve all your goals quickly, but small wins and steady progress mean you’ll enjoy the journey of continually improving how you work.

Do your team members have a problem they can’t solve? Maybe it’s time to try impact mapping. In this article, noted author Lisa Crispin shows us how she uses impact mapping to solve problems. Impact mapping takes a lot from other brainstorming and planning tools, such as mind mapping and story mapping.

With all of the choices available to software developers, it's easy to become overwhelmed not only by a problem but also by its many possible solutions. One approach that can help you and your team stay on track is to divide and conquer.

Lisa Crispin shares some helpful tools she has come across in her software career. Although Lisa has written automated test code since the early '90s, in the past year she's collaborated more with coder and tester teammates to write maintainable, DRY, automated test code.

Studies show that programmers who pair produce higher-quality code at faster rates. How can testers work better in pairs? Lisa Crispin offers some tips from personal experience.

Often, when I comment on someone's blog post or respond to a tweet with a story about how my team succeeded with some practice, someone replies, "Yeah, but your team is special." I interpret this as meaning, "You're a presenter and book author. You must be an expert, so of course your team can do anything." This frustrates the heck out of me.

Test automation can turn into a real pain in the neck if a designated team is in charge of it or if the automators work on it as a separate project. In this article, Lisa Crispin seconds Bob Jones’s recent call for whole-team test automation and elaborates on the dangers of relegating test automation to an isolated project rather than integrating it into the overall software development process.

I often receive emails from recruiters that go something like this:

We are looking for a talented QA Engineer experienced in /test automation|Java|C#/ for our /test automation team|agile team/. Can you refer anyone?

*scream*

Here's what I replied to the latest one (I really did! I've only edited a little!):

Dear Recruiter,

When Lisa Crispin’s team got an opportunity to put the story mapping ideas she picked up from Jeff Patton into practice, they excitedly rushed into it and missed a few steps. Find out what happened, what didn't happen, and what they learned from it all.

Lisa Crispin reviews Bob Martin's "The Clean Coder". She says that she would have preferred something like "The Software Professional" or "How to Really Enjoy Your Software Career." According to Lisa, the lessons in this book are essential for everyone involved in delivering software, not only the programmers.

In this interview, author, speaker, and agile tester Lisa Crispin speaks with Simon Baker, cofounder of Energized Work and recipient of the Gordon Pask award, about the approaches and tools his lab uses.

Lisa Crispin's team recently faced a slowdown in the flow of requirements for a project. They were waiting on the product owner, who was swamped, but he was waiting on someone, too. To beat the waiting game, they tried a small experiment involving smiles, frowns, and deadlines. In this article, she describes how the experiment turned out and suggests looking to experimentation when things get tricky.

I always recommend to teams newly transitioning to agile that they keep every iteration the same length. This helps them learn to manage their time, and after a few iterations they'll start to get a rhythm. Hopefully, they'll learn to work incrementally, doing testing and coding concurrently as part of one development effort, so that user stories are finished throughout the iteration, and testing isn't pushed to the last day.

If you asked anyone on my team what agile practice is most responsible for our success over the past eight years, I bet they'd say retrospectives. But I wonder if it's not so much the retrospectives themselves, as the "small experiments" (to borrow Linda Rising's term) we perform to try to address our problem areas.

Information technology changes fast, and none of us knows what our future holds. It’s hard to keep up with new programming languages, patterns, tools, frameworks, design techniques, and practices. If you’re a programmer who doesn’t keep her skills up to date, you won’t get the best job opportunities—in fact, you might not get any. Yet, we observe many people who call themselves testers or quality assurance professionals but don’t make much effort to learn new things.

The estimation roller coaster can provide an unwelcome burst of adrenaline to an otherwise smoothly running project. Adapting estimates over time lets you plan and deliver value at a sustainable pace.

My team is in the middle of one of the hardest projects—we call them "themes"—we’ve ever tackled. We’re a high-functioning agile team that has helped our company grow and succeed over several years now—we “went agile” in 2003. Here’s one thing I know for sure: No matter how many problems you solve, new challenges will pop up.

Lisa Crispin dives into the "we're all in the same boat" theory and explains how it can't be more true in the software development world. From the need for common goals to going beyond taking responsibility for the team's actions, each team must know that you're going to fail or succeed together.

When a tester joins an agile team, she leaves her Test or QA team behind. Often, her old QA team is disbanded altogether. Without the support of a QA team, she might feel abandoned, especially if she now reports to a development manager. She’s in danger of becoming isolated, having lost the phased and gated process that guided her old team. She may feel pushed to the sidelines and like she’s lost any control over quality.

For those who believe there has to be one right way to do something, especially in software development - there can be. But that one way isn't likely to come from a single individual. Through collaboration and teamwork, some of the greatest single ideas have evolved.

XP teams have the right to do their best work. On the other hand, customers have the right to specify and pay for only the quality they need. How does one reconcile two potentially conflicting points of view? Is quality negotiable? If so, how do we go about negotiating it? This paper will explore the following questions: Is quality negotiable? How can we negotiate quality? What are internal and external quality, and are either or both negotiable? What's the XP tester's quality assurance role? How far should testers go in helping the customer define acceptance criteria?

As a veteran of two startups, TRIP.com, a travel Web site, and Tensegrent, a software development company, I have learned some lessons the hard way about implementing quality assurance in a web startup environment. This paper gives some guidelines based on this experience: How to get buy-in from management, how to educate yourself about Web testing, how to implement a useful process, how to prevent a testing bottleneck.