How Collaboration Changes the Way Testers Think
By: 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.
I started my software career as a programmer-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.
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-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.
... to read more articles, visit http://sqa.fyicenter.com/art/