This is a guest post by Rachel Kibler.
I have a law degree and practiced law for a few years before becoming a software tester. (It was awful, but that’s a story for another time.) While a lawyer, I read a lot of contracts, parsed legal cases, and spent hours in libraries poring over decades-old phone books for fact-finding missions.
When I turned to testing, I was sure that a lot of the same skills and traits would translate, like creativity, analytical thinking, being detail-oriented, and listening well. A company hired me on faith, for which I am eternally grateful.
At that first company, I was on a project where we were integrating a vendor’s product into ours. It was a complicated application that added brand-new functionality, and we spent a long time testing the integration and the application itself. We were working in waterfall, and the testing happened all at once and took months.
After testing for a while, I looked at the terms and conditions that we were adding to the website. Lots of things were wrong. We talked about the use of data incorrectly, the timeframe for things to clear was incorrect, there were grammatical issues, and there were a lot of other problems. I redlined the terms, with comments, and asked that they be sent back to the lawyers for review and correction.
As with most relationships, particularly loose ones, there is a balance between improving things and protecting egos. This was no different, and it was perhaps more fraught, as we worked through a person in the middle to get the terms right. I wanted things to be right (and, well, I wanted to be right), and they didn’t particularly like being corrected.
I assumed they would want to describe the product in accurate terms and disclose exactly what was going on with the data we collected. And, for the most part, they did. They came back with updated terms for me to review, but they quibbled with a few of my points. They liked the run-on sentences, oddly enough. We went back and forth a few times about the use of data, but we settled on terms that were both accurate (for the most part) and protected the company.
My role as a tester meant that I understood the product more than most people, even those on the project. I certainly knew the product better than lawyers who had never touched it. The lawyers listened to me and changed what they wrote because I spoke up.
Being a lawyer myself certainly helped in this situation, but I think I could have argued for the same points, even without that experience.
As testers, we are uniquely situated to talk about the product and understand what it means, and we are detail-oriented and analyze risk well. This all comes together in being able to assert that the terms are inaccurate, wrong or misleading.
My Exhortation
So here’s my exhortation: Don’t be afraid to rely on your past experiences to improve the software you work on now. We don’t need to be interchangeable testers, and being able to offer value in a way that we are uniquely able to do makes our software better.
As a postscript, other companies haven’t responded as well to my reading terms or contracts. One company, after I told them for the third time that I had a bad employment contract, still told me they were unwilling to change it, and I had to dig up another person’s contract to prove that I did, indeed, have an outdated and bad one.
My current company listens to me when I proof error messages, and it’s just a matter of time before I insert myself into reviewing other customer-facing language. I’ll be brave, and you should be too!
Rachel Kibler is a tester at 1-800 Contacts. She can be found online at racheljoi.com and on Twitter @racheljoi.
