The Blind Fisherman (Part 1)
The fine line testers tread between “If you see something, say it,” and “Don’t be so annoying!”
How you know the Blind Fisherman has caught something:
During planning or testing, a tester raises a question, makes an observation, tries to clarify an explanation given to her by offering her own ‘counter-interpretation’ — and this leads to a refinement in the dialogue. Sometimes it leads to uncovering potential bugs or improvements. After saying whatever the tester felt moved to say, if it was relevant, a little light flashes in the sparkly-eyes of, let’s say a Product Owner or Developer. You might hear an enlightened noise in a high-register (“ahhhh!”) or an uttered phrase (“you know what, you may be onto something there!…”) Others may go quiet, become thoughtful, politely walk away and go in a totally different direction with their code. In those moments, the tester knows that she has (somehow) helped to catch a fish, and it feels great.
Why call it a Blind Fisherman? Because the code, to me, as a tester, is often like what goes on below the water. I really don’t know all of the in’s and out’s, and the deeper into the universe of code I go, the murkier and more obscure it gets. I may know a few general patterns, or apply systems thinking to make some common-sense predictions, but my lack of deep coding expertise prevents me from getting too specific. Likewise, even when I’ve helped uncover something (“catch a fish!”) I can’t take too much pride in it, or even have a feeling of “accomplishment” (in other words, I am kept hungry). And yet, at the same time, undeniably, I was the catalyst, I said something, literally playing a key role in a crucial moment.
I’m most interested in the team-dynamics and social-mechanics behind these magic moments when testers can be catalysts and say that perfect thing. What conditions allow such feedback to happen? Blind Fishermen may not have full use of their eyes, but they do have their skills, their experience, familiar places they go to fish, and perhaps a few tools. More than anything though, it is an attitude of humility, watchfulness and receptiveness that must be applied to the following two stipulations:
One. Fisherman spends time fishing (or, Tester has to have spent time on the product.)
Two. Fisherman gets to know his environment (or, Tester has to have spent time with the developers/culture).
I’ll talk about number two first because — agile man that I am — I prefer people over tools and processes! (We’ll get to number one in the next article.) For now, here’s a personal story that is a sort of parable for how communication, inter team dynamics / foundations can be set.
PEOPLE (on a bus)
When I first started secondary school at around 11 years of age, I used to take the bus home (that exact bus pictured above!). I had a best friend who was cool, which meant that he was able to sit on the upper deck, all the way at the back (where the cool kids sat). These kids were way older and way tougher. Because he was my friend, I got to sit up there with him. I was aware that occupying that space on the bus was something of an honour. I sat tentatively, and I didn’t talk much except to my friend here and there. I wanted to join in and talk to the cool older kids, of course, but I resisted the urge to say too much (since I was new).
One day (while still in the “new” phase) there was a huge fight at the bus stop before we got on. I arrived late and got onto the bus without seeing much of what happened. Once it settled down, one of the cool kids who had been in the fight came up to sit in his usual place at the back of the bus (as he walked past me he was a little bloodied, still swearing and shouting loudly). Something possessed me to say something to diffuse his anger. He looked at me, scrunched his face up in confusion, and told me that I didn’t know what I was talking about, and that I should shut up. It was quite embarrassing, and also informative. It was also true that I didn’t know what the situation was at all because I hadn’t witnessed it, so good intentions aside, he was actually totally right. I hadn’t spent enough time on the bus, or in that specific situation, to merit the elevated status of “having a voice worth listening to.”
PEOPLE (IN SOFTWARE TEAMS)
The basic concept is, I feel, analogous to how a new tester must first establish themselves with their peers when they join a team. That means observation (sometimes silent observation!) It has always amazed me to see new hires join a team and come right in with an in-your-face attitude (even more amazing if they expect this will actually yield positive results!) At times such an approach can be understood and forgiven as a talented (and very motivated) worker trying to show what they are capable of. But for the most part, checking out the team vibe and culture are the first (and most crucial) steps that new testers can take to eventually gain the trust of their colleagues. I’ve almost lost count of how many talented employees I’ve seen arrive at a job only to be gone within a few months because they just didn’t give themselves a chance to be successful.
Just as you need time to be able to see how the people are, you then also need to let them see who you are. “Who you are,” from a work perspective, is largely about how you speak, the kinds of angles you tend to come at things from, how you listen, how you understand, how you respond to the kind of humor and events that are prevalent in that work culture. When people see these things, and like what they see (or at least don’t hate it, and get used to it), they will inevitably become more open and receptive to your input. Being more open and receptive to your input means they actually allow the things you say to penetrate their minds, to actually register; they give your words a chance to marinate, set, and travel down a few pathways in their own mind. This is what leads to them listening at that crucial juncture, when you speak up with one of those inspired observations, questions, etc.
SUMMARY
The thin-line a tester walks (as mentioned at the start of this article) is a very real thing. Reputation is crucial in software testing, as it is in any walk of life. If you too carelessly say whatever comes to mind, you may risk wasting the time of your fellow developers, thus lowering yourself in their esteem, and ultimately closing their minds to you. On the other hand, saying nothing could rob you of the chance to play a part in the development or improvement of the product, and ultimately the team. What to say then is often just a case of timing.
Spending (i.e. sacrificing) some of your own time to quietly study that product at your job is perhaps the most valuable investment you can make as a tester. Doing so decreases the time you have to spend asking basic questions to developers, and increases the chance that what you do say is more relevant, closer to the heart of the matter.
