Sparking change as a testing practitioner

How can a testing practitioner spark change in their teams? When I tell stories of how I got my teams to try new things, some folks say, “Well, Lisa, you’ve written all these books and of course your team listens to you.” Hah, I can tell you that my writing and speaking generally failed to impress my own teams. Still, what if I share some stories from before i ever got into co-writing books and pairing on conference sessions?

A story from waterfall days

Back in the mid-90s I worked for a database software company that followed a waterfall process. In those days, our customers didn’t want changes any more frequently than every six to twelve months. We had all the phases – analysis, requirements, design, coding, testing, release. And, it must be said, we also used a lot of modern development practices, including close to 100% test coverage at unit level along with good coverage at UI level, continuous integration, and automated deployment.

It was a pretty healthy, forward-thinking, psychologically safe culture. It was quite diverse too, with people from different countries, and lots of women in management, including the VP of development. Still, I was on a “QA” team, and we had a test phase that followed the end of the coding phase.

Testing a requirements doc

I had been to my first testing conference, and the one valuable session for me there was a woman (I do wish I could remember her name) who explained how we could test requirements documents. I obtained the requirements doc for the new features that were underway for the next release (which of course was some months away). The printout was close to a half-inch (about 1.25 cm) thick. And it contained significant issues such as conflicting requirements that contradicted each other, unexplained assumptions, and ambiguous requirements. (An internet search did not find me any good articles on testing requirements documents today, which is probably a good thing!)

I went to talk to one of the business analysts who had helped document the requirements. I asked her to go through the doc with me and help me understand it better. She was quite happy that these issues had come to the surface before the coding phase began! Another requirements meeting was held, and this time, I was invited along.

Getting involved early

After that, I made sure I found out about all upcoming requirements meetings. I encouraged other testers on my team to get involved as well. This naturally led to us participating in the analysis meetings as well. Our team ended up with requirements that were understandable and more likely to be what customers wanted. We testers were able to explain them better to the developers when they began writing the code to implement the changes. We enjoyed closer collaboration among the different specialist roles throughout each development phase.

Our product quality rose along with our process quality. There were lots of factors in eventually achieving a whole quarter where we had no critical customer support calls (yeah, customers still called support on the phone back then). Testing requirements documents, which led to closer collaboration in the early stages of development, prevented lots of bugs and re-work.

Sparking change

I was “just a tester” on that team, not a team lead, not in an obvious position of influence. I was lucky to work in a safe environment where it was ok to elbow my way into a requirements meeting if I wanted. Maybe this comes down to building relationships. Though I’m a shy person, I was brave enough to start talking to the BAs about requirements. Sometimes, we can be a change agent by going outside of our defined role and asking people in other specialties and teams to help us out.

Watch this space for more stories from my distant past where I got my teams to try something new!

And just to be clear, I’m not encouraging anyone to write requirements documents! These days, we aim to build quality in by getting shared understanding across the delivery team and stakeholders.

The post Sparking change as a testing practitioner appeared first on Holistic Testing with Lisa Crispin.