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.
I started my software career as a programmer and analyst. In my first job, we collaborated directly with customers—we didn’t know about requirements docs and test phases. Subsequent jobs introduced me to waterfall development.
When I started working as a tester, I still collaborated as much as I could with programmers and product managers, but I totally acquired the “Quality Police” mentality. It was up to us testers whether the software was ready to release to production! We were the gatekeepers.
Agile Mindset Shift
At the end of my first iteration on an Extreme Programming team, back in 2000, I told the team we couldn’t release the code because if two people logged on to the application we had developed, the server would crash. This was obviously unacceptable!
Our coach patiently explained to me that it was not my call. Our customer didn’t care about more than one user logging in at one time. They were a startup and wanted features to demo to potential investors.
This was really hard to swallow. The server was crashing! Slowly I snapped out of Quality Police mode. I, as a tester, don’t own external quality; our customer does. That was the hardest thing I’ve ever had to learn in my transition to agile development, and I’m glad that I learned it so early.
Show Me
During my years as a tester on waterfall teams, I was keen on defect tracking systems (DTS). And the more customizable and complicated they were, the better I liked them. I spent hours redesigning our workflows. What metrics I could get out of them!
Cut back to that first Extreme Programming team. I was sitting in the same room as all the programmers. It seemed silly to enter a bug into a DTS when I could simply walk over and show it to one of the programmer pairs or stick an index card up on the wall.
The programmers also found it saved them time to call me over before they checked in code for a new story so that they could walk through what they had just done with me. If I had any questions or observations, they could take care of them right away. Janet Gregory calls this “Show me.” Not only did it save time, it got us in the habit of working together, regardless of our specialties on the team.
Learning the Domain
I was lucky early in my programming career to get to work closely with domain experts. I was a programmer and analyst on the first online catalog at the University of Texas Libraries. I had to write the code to take unformatted catalog records that spanned tapes, parse out the data, and insert it into the database. I worked together with a librarian to learn the Library of Congress and Online Computer Library Center cataloging systems. Library science is fascinating! But more importantly, I learned the value of collaborating directly with end-users and stakeholders to quickly learn the business domain.
These skills were especially useful when I started working on agile teams. I think my most valuable contribution to most of my teams is my ability to pick up the business domain quickly. I know how to seek out the experts and think of good questions to ask.
Some domains were difficult to learn. For example, in financial services I had to not only understand how mutual fund trades are processed by clearinghouses, but also memorize the not-very-logical and arcane government regulations. It was rewarding when other delivery team members and operations staff came to me with their questions about how the systems should work and I was able to help. I can help build the right thing.
Planning for Testing
Back in my waterfall days, I spent so much time crafting lovely test plans in huge Word documents. Nobody besides me ever read these, but hey, it was my job. Another part of my job was automating tests. I like to write code, so this was fun, even though it took a lot more time than it probably should have.
Acquiring a shared understanding of how new features should work by having conversations with business experts and other development team members was a huge improvement. My ability to write test cases was still useful, but now I can collaborate with the product owner, customers, and other stakeholders to specify examples that clarify desired and undesired behavior. And I can collaborate with programmers to automate those, guiding development with business-facing examples. Our automated regression tests running in our continuous integration provide a short feedback loop, and they’re inexpensive to maintain.
I’ve discovered there are lots of different ways to plan testing. Getting people together to draw a mind map of what testing needs to be done for a feature is a powerful way to brainstorm ideas. The mind map provides a reference point for continued discussions and even to track testing progress. The outcomes of all this collaboration is far more powerful than any test plan I could write by myself.
Exploratory Testing
With all or most of our regression testing automated, we have loads of time for exploratory testing. This is another area where I can add value, even by myself. But it turns out that exploring in pairs or groups can be a lot more valuable. I pair with other testers, with product owners and other customers, with designers, with programmers, and with database experts to execute test charters and look for risky areas.
On my current team, we sometimes get several programmer pairs or even the entire team conducting what we call a “group hug,” sometimes executing charters and sometimes doing a free-for-all bug hunt. When I write charters, I design them so that anyone can understand where to focus for that charter. I can expand my thinking around exploratory testing, because there’s a whole team involved in doing it.
The Whole-Team Approach
The biggest way collaboration changes how I think as a tester is the fact that the whole team takes responsibility for building quality into the product. Testing activities for each story, feature, iteration, and release are owned by the whole team. Anyone on the team can sign up to do a testing task. If something gets in the way of testing, the whole team can think of experiments to work around it. If testing is falling behind and many delivered stories are waiting to be accepted, other team members step in to help.
It takes courage to evolve from being a tester in a gatekeeper role to working as part of a team that’s taken responsibility for quality. I had a hard time learning to ask for help. I didn’t want to bother busy people, and asking for help seemed like an admission of ignorance.
But once I had experienced collaboration, I loved how rewarding it felt. When my team is planning a new feature, I don’t just think about how I will test it; I think about how we can work together to make sure it will be valuable to our customers. And I know the rest of the team is thinking this way, too. Even when I’m the lone tester on a team—as I often have been—I’m never alone when I collaborate.
