I know nothing
While hunting for bugs, there is a high risk to fall into the trap of not noticing stuff, due to biases like confirmation, neglect of probability, observer expectancy etc. There are several ways to deal with this. One that I like practicing is to think that I know nothing and the information I was given may not be true.
This attitude helps outside bug hunting too, reminding me that I don’t know everything and the things I know may not be true. For example, let’s suppose you and I are engaged in a conversation about a testing webinar we’ve both seen. Then you say something I don’t remember seeing in the webinar. Keeping in mind that I don’t know everything helps me to first listen to you and your argument, instead of reacting to what you said as not being true. After listening to you I may find out that what you said is a result of your personal interpretation of what the speaker said. This new interpretation is valuable for me to understand why I interpreted differently. I may also find that for a fraction of time I was not paying attention to the webinar. My mind could have just rambled with the previous idea the speaker said, so it’s a good opportunity to catch up on what I missed. I may realize as well that I jumped to conclusions too early. In any case, no matter my findings, I have observed that the attitude of ‘knowing nothing’ shortens the time to getting to understand what the other has to say and avoids conflicts.
The physicist Richard Feynman has a nice video talking about Not knowing things [00:00:57]. It is part of a longer recording that can be found here Richard Feynman – The Pleasure Of Finding Things Out [00:49:38]
For me it’s a pass. What if for you it’s a fail?
When we run tests and analyze the results, we testers may not always have the relevant information to say if something is a bug or not. There are two cases here. First, when we mark a scenario as a fail, but for the stakeholders it’s a pass. And second, when we mark a scenario as a pass, but for the stakeholders it’s a fail. I have experienced both cases, but the second one is a bit more painful because it doesn’t even feel fishy to get to question the test result. In time, I have developed different mechanisms to avoid this, e.g instead of writing pass or fail for a scenario, I write the actual result of the test and then have that reviewed. This helps to identify false passes. The good side effect is the double check of where I looked for scenario impact – sometimes I should also look in logs, network calls, sent emails, analytics or another functionality and I just forget or I’m not aware of their existence. Repeated experience with the second case, also led to questionings of the ‘obvious’, which many times is interpreted as a lack on my side. Asking self-evident questions has become very important to me. How easily I can get fooled by not doing it! Observing the good results, fortunately I don’t find it that hard anymore to overcome the fear of looking silly.
I noticed I started to do this outside work as well. Most of the times I get reactions like “really, you don’t know that?” or answers to other questions I did not ask. It’s hard for people to imagine that someone would ask such an obvious question. Sometimes it’s a fun situation, other times confusing and frustrating. My opinion is that as long as the confusion or frustration causes people to ask themselves questions then it’s beneficial, even if the feeling itself is not very pleasant.
Next, I’d like to share a comic I love, related to questions and answers: A day at the park – Mused
I used to have sprint demos/reviews in some projects I worked on. During those meetings, we showed the product owner the new features. Did it ever happen to you that the product owner had a different perspective on how the features should behave? When this first happened to me I worked to avoid the situation for the future. Back then I thought that the resolution stands only in my skills set. But then I realized that it’s beyond my area of control. Learning more about sprints, I understood that the demo meetings exist exactly for this reason: to get fast feedback when the team implementation is offtrack.
In day to day life, I started to feel the need of asking for feedback. In the past, I used to get upset when someone shared a different perspective than mine, and took it as a critique. Now, I get less and less grumpy when this happens. I even ask for feedback sometimes (when I feel really really brave). I still take it as a critique, but I find it constructive. Going further with this, there are other ways to look for feedback. We can exploit other verification mechanisms as well. For example sending emails with what we understood after a discussion, checking the information across more sources, offering visibility into our work etc.
The list can continue with many other things I learned from software testing activities. A level higher, testing as a job (or part of our job) is a hint to stop being ashamed of our own mistakes. As long as we spot & ‘fix’ them, it’s good progress. Software is in a continuous change. We are in a continuous change.