We often focus on the technical skills required to be a good tester. For sure thatās important.
Yet itās important to also focus on soft/human skills.
It was great to read the replies to this question via LinkedIn.
Empathy and imagination! Really helps when youāre thinking of the wildest scenarios and people say āno user is going to do thatā.
The ability to laugh in the face of frustrating ābugsā ā they canāt handle your cheerful spirit! Joke! Maybe, touch of creativity ā because finding bugs requires thinking outside the box (or maybe inside the code).
Curiosity
Persuasion, assertiveness, critical thinking and problem solving skills.
How about you, what would you add? What can you share from your own experiences?
What soft/human skills are critical for being a good tester?
Iām so glad you asked this as its easily overlooked. Too much effort is spent on tech skills and the people skills get neglected.
Iāve done a few talks on this and to my mind testers need to have the following:
Good communication skills, both written and verbal
Analytical skills
Inquisitiveness
Good questioning skills
Thinking laterally
Empathy - putting themselves in the place of the end user
And those mentioned above - imagination, persuasiveness and assertiveness are crucial!
I do love that a sense of humour was called out
As I grow older, but not wiser, I find that I could have gotten a lot more done in my past if I had known who I am. I would have been a lot less of a pain to work with, and more effective as a team member. To narrow down which of the soft-skill attributes matter most for the role of tester, and not just any software engineering role is tricker to separate out.
And it mostly reminds me of the domain problem of white-box /black-box problems. Testers face far more black-box than for example a product-coder does. So an ability to build theories, on systems that are going to often be undocumented and opaque, and boil them down quickly and not get frustrated by lack of information. When you do not control a system and have freedom to experiment, you have to change your problem-analysis technique and energy significantly.
And I think thatās why we often say that testers need more imagination when it comes to problem solving. Most product failures are often not complex, they are just more complex than the one buggy line of code the developer wrote if you really boil it down. A line of code that often the tester cannot even see. And an ability to dissect those wildest scenarios and not give up helps.
Imagine what a customer goes through, because they have not got access to all that knowledge to help them troubleshoot when something unexpected happens. Testers do understand the frustration of users, but we are required to turn our empathy into tactical empathy. (Tactical empathy is like Cognitive empathy for those that follow a three kinds of empathy theory; but where tactical empathy deploys all of the empathy kinds over the lifecycle of the problem not as a negotiation tool, but as a way to explore understanding that is in multiple peopleās heads.)
We more often need to have memory like an elephant sometimes too, to be able to recall a customer complaint about an issue and link that to intermittent bugs that may crop up months later for example.
So. A small pinch of cheerfulness too, which is something Iāve subconsciously been cultivating the last while and doing so more consciously lately seems to be key to that never-give-up attitude when you encounter hurdles and have to leave things on the backburner until more facts arrive.
I wonder if other people are going to really just come up with versions of Simons list like I have, this is quite bizarre, but helpful thing to sit down and work out.
Weāre often in the position of giving someone bad news - telling the developers thereās something wrong with their baby, telling a product manager the latest feature needs a lot more work before it can be safely released, and so on. This one is hard for me, because my natural mode is anything but tactful (Iāve been known to tell people āIām Australian. We donāt call a spade a spade, we call it a f*****g shovel.ā) Iāve also been known to say (in the middle of a very nasty project that spawned a ridiculous number of bugs) to a dev, āIām really not trying to ruin your life.ā
I think empathy is required in both ways: putting ourselves in the place of the customer, but also understanding what the developer needs do know to implement a feature or fix a bug.
Iād also like to add:
good organizational skills, for example how and where do I store information
Be social! As a QA that works really close to the dev team, I feel that having normal conversation (āhowās your day? letās grab a beer after work?!ā types of convo lol) with my colleagues helps a lot when I need to talk about anything serious later (like telling them thereās a bug they need to fix ).
Iāve been through something awful in the past that marked me a bit.
So I have to distinguish between being seen as a good tester and being good at testing.
Characters of people in the past that were seen as good testers (regardless of their testing skills):
very sociable;
talks a lot;
agrees almost all the time with managers;
shows servitude;
can lie, bend the truth;
presents facts in a positive manner;
anything can be done attitude;
As for being good at testing, plenty of directions have been mentioned.
Although I think you only need a few of those, not all of them.
Mean, want to spoil the thing and find all bugs
Good communication, especially within the development team, but also with users and project leading people
Good common sense
Not necessarily good programming skills(ie. automation)
One I often find that gets overlooked is being adaptable
As a discipline we cover such a wide array of things that just going from project to project within the same company relies on us being able to adapt, adjust and understand quickly. From coding Automated checks to understanding accessibility requirements
Listen - I know this might fall under communication skills but being able to listen is a crucial skill in our work so I am emphasizing it.
Be realistic in estimating time and effort - This is a pet peeve of mine since I have been burned in the past. It really grinds my gear when people would give an overly optimistic estimate when there are usually unknown unknowns that cause delay. (Even worse when people who gives the optimistic estimate are often the ones who are delayed themselves)
I agree that persuasion is such an important soft skill for people in Quality roles. If you are the only tester on your sprint team then it might be up to you to persuade multiple people of the severity of a bug, to hold off releasing a build, or to spend more time testing. And this may be necessary when itās not going to be a popular decision, so being able to use reasoning, logic and pragmatism to convince others is super important.
Over the years Iāve also found consciously trying to come off as friendly and understanding as possible all the time in calls, meetings or messages has helped when dealing with less fun situations. For example when giving feedback, reporting on bugs during development, or sending a task back if requirements havenāt been met.
I think those conversations for the developers can be inherently difficult because itās effectively saying, āyou need to do this!ā. Understandably if theyāve put a lot of effort into something, itās tough for them to hear. So without being friendly generally, you start off on more neutral ground, so those tough conversations may be less well received. So I would say, being friendly is an important soft skill!
I donāt like to call it mean. Maybe youāll need some sort of resilience or tenacity when you talk to someone who is responsible for a certain part of the software, you find a bug in that part and they are completely in denial about it.
Maybe they say, youāre spoiling it. But you - as a tester - only reveal the defect that has already been there.
You are only the messenger, not the causer of the bad news.
I like to, and all the great troubleshooters Iāve met during my decades in SW development, has a kind of Dr Jerkyll/Mr Hyde personalityā¦
You gotta be perceived as a person easy to talk to, having good communication skills, but at the same time the &%&%Ā¤ that you never can release code to without finding all the bugs.
I like the idea of being friendly as a skill, because it puts the emphasis on forming professional relationships and thinking about how we come across in communication, rather than it being an inherent characteristic we either have or donāt have, or needing to genuinely like the people we are working with, which unfortunately canāt always be the case.
Also as opposed to being just nice, being friendly will involve conveying unpleasant news too, but with the understanding that this is for the greater good and we are ultimately on the same side
Joke! Maybe, touch of creativity ā because finding bugs requires thinking outside the box (or maybe inside the code).
).