I am a psychology graduate and I practiced psychology for a few years after my studies. After some time, I realized that being a therapist is not my vocation. There was an urge to help people inside me, but I realized that this was just not my path.
I was always an IT enthusiast and I decided to steer my life path in this direction. After some time I landed a job at Slido, where I learned a great deal and where I am now team lead of our QA department.
When people find out about my background in psychology, they are often surprised. But then they quickly add that it can actually help me a lot in my job. I agree with that. I like to say that once you study psychology, you can never look at the world the same way. It builds up thought patterns that influence how you think. I thought I’d share a few of these patterns in this blog, hoping they will influence you in a positive way. They certainly did that for me in my role as a tester.
What drives people’s behavior? Freud said it is unresolved conflicts from childhood, Maslow talked about hierarchy of needs, Frankl said that it’s the meaning that drives us and James said it’s learned behavioral patterns. Whichever it may be, the question of what drives us was burning enough to create a myriad schools of thought. It goes without saying that it is an important question (maybe even the most important in psychology). And it stuck with me when I started testing software.
Looking at a new feature, I listen carefully to what the product intention is, but more importantly, I look at motivations of the end user. It is often really hard, but also really valuable to put yourself in someone else’s shoes and see the world from their perspective. In my view, it is vital that testers do that. Just for a minute, imagine users’ problems as your own. It helps you to think as someone who needs that problem solved. It unfolds the motivation that manifests in user behavior. It helps you to understand that behavior.
I love to demonstrate this via this joke:
<script>A QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 99999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd.
— Brenan Keller (@brenankeller) November 30, 2018
First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.
Some of us know the feeling of when this happens. Users’ needs are often different from our intentions. Those needs, however, need to be taken into account when testing. As testers we should make our best effort not to be blind to those needs. If we try to focus solely on making a product that is “perfect” in our own view, we risk that it may not be so great in the eyes of our users.
I remember back in university when we did a therapy role play and I was in the role of therapist for the first time. Sitting across was my colleague questioning my competence to counsel as a family therapist while being childless. This was a tough setting. While doubts and accusations kept on coming, I tried to defend myself. Of course, it was a big failure, but it was also a good impulse for a discussion on what went wrong.
Our Professor told me: „You were trying to defend your ego, being totally oblivious to what the person sitting in front of you was *really *trying to say. Step outside of yourself and try to shift your focus to the other person.“
This made me realize that instead of trying to prove myself, I should have listened to the doubts and anger of the person sitting in front of me I could have found out — that she was trying to tell me about her fear from not being understood. That was a good lesson to learn.
We testers often try to prove our value to the world (and maybe to ourselves, too). Understandably so, since it is not always that obvious where the value of our work comes from. As a result, we create some cool names for ourselves, like QA. Although I use the QA abbreviation too, I don’t really like the meaning — quality assurance. To me, it completely removes some essential elements of the context — mostly people and their emotions. I often find myself going back to that classroom and think about what is *really *being said. When we work on a product, how does it really impact a user’s life? I think Isabel Evans said it best:
Shift the focus from software to people. It is vital to think about those emotions and be able to name them. Don’t focus solely on assuring quality, but also on evoking the right emotions when using your product.
What do I mean by that? I can give you an example from Slido. It is being used at live events, presentations and in company meetings. There is already a variety of emotions present in that scenario. Stress, time pressure, battle with unexpected situations, urge to fulfill various expectations etc. When entering this environment, we can either be helpful with our product, or cause a big frustration. Even a small bug can result in losing a customer’s trust.
This is an angle I really need to work with when testing out new features, writing automation etc. Looking at user emotions helps me look beyond what’s functioning and what’s not. It helps me understand what happens in a user’s head when they are using a certain feature.
When talking to someone about their personal problem, it is often tempting to share your own experience. It actually makes a lot of sense. If you went through a similar situation, you want to offer a solution that worked for you — maybe it will help. The big problem with that is that your experience is totally different from the experiences of others. There is no better way to help someone with a problem than to guide them and to help them find a solution on their own*. Most of the time, advice does not work. There’s actually a nice little joke about this in the psychologists’ world:
Psychologists barely give you any advice in therapy. That is because they are very aware of the fact that their own experience is in no way applicable to your own situation.
We all think we can be objective (to a certain extent), but we often fall into a trap with our own biases. We are all using assumptions, and we are doing that daily:
„Oh I know what this is about.“ — Seeing a bug report for the first time
„Everyone’s going to love this!“ — Finishing testing of a feature
„No one is going to do that.“ — Waving hand at a benign issue we just don’t have enough time to fix before release
Sound familiar? I remember many situations where I would slap my forehead after I realized I was wrong with my assumptions. The biggest problem was that I didn’t realize they were assumptions and thought of them as facts.
We all have assumptions and it is impossible to not have them. You may attempt to get rid of them, but you might end up just fooling yourself into thinking that you did.
That does not mean, though, that you cannot do anything about them. The best thing you can do is to acknowledge you have them.
The upside of knowing the difference between fact and opinion is that it enables you to make good decisions. I bet that in the life of a tester there are many crucial decisions that have a deep impact on the product.
Testers work closely with developers. While a new feature is being developed, they spend most of their day giving feedback on those features. The way you give that feedback can make a big difference.
When dealing with married couples’ problems, there is a false assumption that *communication solves every problem. *Actually, if your communication is aggressive, not only will it fail to solve any problems, but also it could actually make things much worse.
And yes, I just compared developers and testers to married couples.
Good communication has a big impact on the face of your relationship though. Whether talking marriage or product team relationships, you can either build them or destroy them. Here are some suggestions on how to make sure you won’t do the latter:
Applies for marriage too.
I recently got into a fight with my colleague. It was a very unfortunate course of events that resulted in waving arms and shouting. I forgot many of my principles that day. All because of a wrong choice of words, which hurt me to my very core. Although meant as a feedback, my first perception was how incredibly stupid and insulting those words were.
Whose problem that was?
Mine.
Underneath a harsh message, there was a valuable feedback which I didn’t listen to. Instead of focusing on *how *the message was delivered, I should have focused on what is being said. It’s easier said than done, but there is actually a good principle that helps unravel even a very poorly constructed feedback:
What that means is that when someone talks about a problem, you can identify a value that is actually held high by that person. E.g. if you hear someone complaining about everyone being late to meetings, you can actually tell that the person values efficiency. If you hear someone complain about number of bugs on product, you can actually tell that the person cares deeply about quality. The list goes on. Next time, if you are annoyed by someone complaining, try to listen carefully and see if you can identify the value they hold precious.
With this in mind, you will be able to see an opportunity to gain even from clumsiest feedback and learn more. I’m not saying it’s easy, you often get overwhelmed by emotions if it’s personal (as did I). But if you take both good and bad feedback, you’ll get twice the opportunity to grow.
*notice that I separate guidance from advice. I view guidance as cooperative and advice as authoritative, although I don’t mean to say that you cannot advice cooperatively and guide authoritatively
From time to time I send some useful tips to your inbox and let you know about upcoming events. Sign up if you want to stay in loop.