This is a guest post by Rachel Kibler.
There’s nothing quite like the first session with a new product. There’s curiosity, eagerness, and a desire to learn and explore, and those feelings are a lot of fun. I enjoy going through flows, reading copy with a fresh eye, and trying to trigger a bunch of errors. I wait with bated breath for the result of SQL injection and JavaScript injection.
My first time going through a banking mobile application, I found a pretty sizable list of bugs. We had a long list of test cases that hadn’t been reviewed in months, and the people who ran the test cases knew the software well enough that they didn’t really consult the test cases anymore. I updated so many of the tests and filed the bugs that didn’t fall in line with what the documentation said.
It felt good to notice things that had been missed for months by the other testers, and I ended up judging them a bit for it. I’m sure I can’t be the only one who’s done this.
Time went on and I became one of those “other” testers. We stopped using those test cases, and when a new tester joined our team and found bugs, I felt defensive. Surely I would have noticed these bugs if they were legitimate! Still, I beat myself up over missing the bugs, and my internal monologue told me I was bad at my job.
However, I quickly realized that there is such a thing as accidental blindness that results from being familiar with a product. Just like dealing with household appliances in a way that we stop noticing—like having to press down for two seconds before the pilot light will ignite on our finicky stove—we pass off bugs in our software as “quirks.” It takes fresh eyes to point out that, no, the stove shouldn’t behave like that, and nor should our software.
I went on, trying to not be so sensitive about bugs. I would tell myself that I contribute a lot more than just finding bugs, and thus, my value as a tester is not dependent on finding all the bugs. I didn’t believe it, though.
I interviewed at a new company, and I was given their software to experience. The hiring manager said, “We have a zero-defect policy. We fix bugs immediately.” Well … you can imagine what happened. I found things from typos to bad flows to unhelpful errors. He left my interview with a list of five bugs to write up for the team.
I got the job, and the world opened up when I started. We have a lot of production monitoring, which I had never done before. We work in continuous deployment, and I test critical and risky paths.
But I still miss stuff. Production monitoring reports bugs before I find them. The call center will report a bug, and it may be an odd situation or just an unintended consequence, but it is fixed quickly.
This was initially hard on my ego, but I’ve come to embrace it. When we work through our stories so quickly, no one is under any expectation that I will “fully test” the software, whatever that means, and they know that I analyze risk more than check flows.
It’s less important that I find all the bugs than that they don’t affect many customers, and that they get fixed when they are found.
Instead of beating myself up over the bugs that I miss, I use the bugs as an opportunity to learn. And, as my colleagues remind me, it’s a team effort to release bugs in the first place!
Rachel Kibler is a tester at 1-800 Contacts. She can be found online at racheljoi.com and on Twitter @racheljoi.
