For the second time during the corona lockdown, Alex Schladebeck, Huib Schoots and Bart Knaack organized an online get-together for testers. They offered and facilitated various activities, and during the last session, I participated in the lean coffee facilitated by Alex.
I was quite happy that one of my proposed topics got selected, but before getting to the details of the discussion, let me explain some background:
About 14 months ago, I joined Finologee as a Senior Software Tester. The role is pretty technical, with a strong focus on technical automated tests (checks). The most technical role I ever had in my 15+ years of being in testing – and I absolutely love it!
But: It’s also very challenging, which as such is not a problem – I love challenges!
It’s so many new frameworks, tools and other various technical things to discover and learn!
I think compared to most software testers, my technical background is quite strong: I did a 3 year traineeship as application developer (german “Fachinformatiker Anwendungsentwicklung”), studied informatics and during my career my focus has been test automation most of the time.Nevertheless, in that new role I feel overwhelmed from time to time: What is that framework for? How do I configure this in Maven? What does this method do? What is the most elegant way to solve that problem in code? And so on…
Quite often I’m searching Google and Stack Overflow for solutions to problems, that probably others have solve a thousand times before – or not. But I don’t want to spend hours looking for something, where there is probably good solution existing and I’m just not finding it because I don’t know the right terms to enter into that search field.
Because one important lesson I learned is “to reach out when stuck!” (shoutout to Deborah Preuss), after an unlucky search on the web, I enter my question into our company’s #dev Slack channel, and most of the times, I get a sufficient answer really quick.
Problem solved, end of story – one might think!
But everytime I ask a question there, I’m asking myself: Is this a stupid question? Should I have known that myself? What will the developers think of me for asking such a “stupid” question? And this is not really making me feel good.Yes, I know, being a software tester and being a programmer are too different roles, with somewhat overlapping, but still very different skill sets. So there’s no shame in not knowing everything, in not being as skilled in programming topics as programmers are.
Still it is bothering me way too often.
So I was happy that my proposed topic “How to not feel ‘stupid’ because as a testers we don’t have the same skillset as programmers?” was discussed during the lean coffee session.
Following things have been discussed in order to overcome this:
Find a mentor
- find one person in the company who mentors you
- it’s not “embarrassing” if you’re officially mentored and asking something compared to asking your question in a slack channel with every developer
Embrace the fact you have „gefährliches Halbwissen“ (knowing just enough to be dangerous)
- it might be enough knowledge about a tool/ framework to get done what you need to do at the moment
Embrace that you have different skills
- Testers and programmers have different skill sets, both are valuable
- You probably know more when it comes to testing, and programmers can learn about testing from you
You’ve been hired for a reason
- The company hiring you did see something in you
- They have seen other candidates, and decided you’re the best to get the job done
Embrace what you don’t know
- It’s ok to not know everything
Pair with people
- It’s a great chance for learning.
- Even if you don’t know much about the code, you will learn something.
- Also the programmer will learn by the questions that you ask
Eine Antwort auf „How not to feel stupid“
I say: embrace your stupidity! One of the most intelligent people I ever worked with would sometimes say „I may be a Bear of Very Little Brain…“* when he came across something he didn’t fully understand – and he held a Doctorate in Economics and wrote several influential books on utility economics.
My company recruited me precisely because I did not have the same technical knowledge as the other testers, but instead had a wide range of varied business experience. My perspective as an „average user“ often cuts past the tech-oriented viewpoint of the other testers and developers. Of course, I’m learning from the other testers – I’ve learnt more about testing in the four years I’ve been in this role than I did in the previous twenty years! – but my focus on users, their likely reactions and the business processes inspired by them gives the team a different perspective.
* The phrase comes from A.A.Milne’s classic children’s book, ‚Winnie-the-Pooh‘.