This is a guest post by Rachel Kibler.
I found myself staring at our website, having gone through the same flows our automation does. I know I can notice some things better than a computer, because, well, we don’t ask the computer to look at everything. The computer is great at doing what it’s told to do, though, yet here I was — recreating the automation manually.
I don’t necessarily believe that I need to find every bug before our customers do, but I do consider trends. When more bugs are being found in production than before, it matters. Our bug count had been steadily increasing over several weeks, with some fairly obscure things but also some pretty standard bugs that I felt I should have caught. I was passing stories through testing really quickly, which was thrilling for the team, because we had a lot of releases, but we were having to fix a lot of bugs separately.
I was labeling most releases as low-risk and then using that as an excuse to do very light, brief, shallow testing. I was getting lazy, basically. I wasn’t engaging with the software or thinking critically; I was just “pushing buttons” without intention.
I was unhappy with this. I felt like my team could tell that I wasn’t doing a good job, but they were hesitant to rebuke me. I didn’t know what to do. I was embarrassed and withdrew further.
The turning point came when I got some welcome reminders about the many different ways testers can think about testing.
One day I received Ministry of Testing’s expansion pack to their TestSphere cards, followed closely by Lena Wiberg’s Would Heu-risk It? cards. Both sets of cards detail test techniques and strategies in a fun way that gets you thinking differently about the concepts.
I started flipping through the decks, and something changed. I looked up Lena’s blog posts about her cards, with more in-depth explanations of each card. I slowed down on the TestSphere cards, reading each one in detail instead of just the titles.
Somehow, once I was reminded that I am part of this huge community of testers who think about testing carefully and passionately, it opened up my creativity again. Seeing other people’s thoughts about testing — but more than that, seeing that other people thought about testing — helped me to pull in the next story with excitement.
We revamped our address form, and we were auto-populating information based on zip code or postal code, at least for a couple countries. I felt like I was prepared for this, and I dove in. I used multiple sites for determining appropriate postal codes for an area. I found bugs in the first pass where international postal codes that also matched U.S. postal codes would switch back to the U.S. Some countries had postal codes that would not validate at all.
I thought harder about things. I could edit the city if it auto-populated the wrong one, but could I edit the state? A quick Google search revealed that there are about a dozen U.S. ZIP codes that map to two states! I tried out some of those, and I couldn’t edit the state. Bingo.
My developer was stunned. I think only the people who live in those ZIP codes care about this issue, and the post office is probably very used to things being addressed incorrectly. For us, this was apparently an existing bug that no one had ever noticed before. The developer fixed it and the rest of the issues, and we now have a new address form.
Testing became exciting again. “Low-risk” no longer meant “don’t worry about it,” but instead became a challenge. I engaged more with my developers and other testers, I read more (and retained more), and I’ve been doing some of the best testing of my life.
Now, when I feel myself start to stare blankly at a screen, I step back, look for community and inspiration, and dive back in.