As a tester it can be easy to focus on the hard/technical skills and how without them you can’t do your job properly (if at all).
Do you know how to code in Java and use Selenium to create an automation script?
Can you query a database using SQL?
Do you know how HTML tags work on a web page?
You might know how to do some or even all of them. But whether you do or don’t, if you focus on learning skills such as those but don’t focus on your soft skills, you will find it difficult to be a tester.
We need to be able to approach people for information and encourage them to share what they know.
We need to be able to pass information back when something has gone wrong and how it was found.
We need to train our peers, new starters, and generally share out the valuable knowledge we have picked up over time.
You could be the ultimate bug magnet, where no matter what you work on you find the problems within it. Anyone who is stuck knows that you will have the answer to what they are trying to do, yet they don’t come to you for help.
Imagine you find a bug/defect/issue/whatever you call it, you walk up the desk of your developer and tell them “You messed this up, fix it!” and then walk away. You will find problems when you then need to go back to the same developer for help with something else later. If someone did that to you, would you feel motivated to help them?
Developers are not the enemy, and this is not a contest where we see if we can prove they did their job badly by finding as many problems as we can with their work, poking holes in it. We are all working towards the same goal, which is producing something that the customer wants/needs, and that it works.
Now, imagine you walked up to the developer with your defect and said “I was just testing the latest release, and I’ve found something that isn’t behaving how I expected it. Can I show you what I found and how I made it happen?” They know there is a problem, but they aren’t being blamed for it, and you’re working with them to understand how it happened instead of just walking away.
They might be busy and can’t spend the time with you now, but you have approached them in a way where they will likely come back to you when they do have the time.
Another example is where a fellow tester is stuck and asks you for advice on how to test something they haven’t used before. You then tell them to read a document they never knew existed, or decide to just do whatever they want to do for them as it will be quicker and you know what you are doing.
In the first case you could appear to be dismissive and that you don’t have time for them, or that you read it and learned how to do it, so why can’t they?
In the second case, you see yourself as saving time and allowing them to continue on with what they need, but for them they didn’t learn how to do it, likely causing them to return to you in the future.
This time, when they come to you for help you start by asking if they read the document you would send them to. Maybe they didn’t know it existed and decide to start off with that first. But perhaps they did and couldn’t understand it, and after trying several times they need someone to explain it in a different way.
Or instead of doing it for them, you talk them through what they need to do, acting as the driver and controlling the actions, whilst you act as the navigator and tell them where to go, which buttons to press, and why. Now they have been able to try it under supervision, able to ask for help whilst they learn from first-hand experience.
Testing is more than just sitting at a computer, designing and executing tests. We mentor, teach, investigate, study, explain, de-brief, and more.
If we can’t speak to others in a way that will help us be testers, if we can’t share our knowledge and experiences with others, we will struggle as testers.