Letter to my fellow tester.

🔵 The text below was published in "Around the World with 80 Software Testers" book. The book draws upon the knowledge and experience from both experts and new voices from around the world involved in software testing.

Don't be shy. Let your voice be heard.

Why? Because your voice is valuable and your opinion matters.

I worked a lot during the past few years trying to empower you, to help you letting your voice be heard. But some of you still preferred to remain quiet, as if opening your mouth to say your opinion was the last thing in the world you would do.

Do you think you're an impostor in the software development team? Don't worry, we all feel that at certain points in our careers, no matter if we're developers, project managers, business analysts, designers, you name it.

The impostor syndrome can affect anyone.

But why you, my fellow tester, why do you pick the silence when your voice would make such a difference if heard?

Well... Maybe due to misconceptions?

Misconceptions

It is well known that some people and companies are seeing your relationship with the developers as a continuous battle, as the developers are the ones working to build something and you to break it. More than that, you, my fellow tester, might get to be marginalised by the fact that you are the "breaker of the system" and your role is not as important as the constructor's (developer) is.

Not even it's a bad approach and an unhealthy way of looking to the tester - developer relationship, but might create you a poor self esteem, making you avoid giving an opinion as you might think you are not good enough or you are not having the power to speak. Wrong!

Misconceptions are affecting your voice as a tester.

Since you're afraid to speak as you're considering yourself as not being as good or as valuable as a developer is, you're prone to end up doing the following mistakes.

Let's have some examples.

▪️ You're in the middle of the planning meeting and everyone is talking about estimations, developers are throwing some numbers based on complexity considerations, but you are not saying anything. Why? Because someone said at some point that testers should not evaluate the complexity of the work that needs to be done, that is a developer's role to do that. Well, it is not only developers' role, but an estimation should also contain the effort that is made by both developers and testers to deliver a certain piece of work.

▪️ You're not asking questions as you are afraid of looking stupid as you are not as technical as a developer is. So? That's the beauty of having diverse roles in a team, great things might be revealed exactly by those non-technical questions that you are asking. And in the end, why is it so bad to ask a question to make things more clear to you? For me, is a sign that you want to evolve, to learn more, to do more to help your team. At certain points in time, everybody is asking a question to which the rest of the team is already knowing the answer.

▪️ The go-live is approaching, you're still having things to be tested and you are pressed by your superior to give the green-light so the features to be released. Nothing fancy, this is happening frequently. But you are not saying anything about the risks that you're seeing, being of afraid of not being able to justify your concerns of postponing the release for a bit. Well, my dear tester, in this situation is more dangerous to remain silent than to speak up loud about your concerns.

▪️ You're receiving the features to be tested when there is not enough time left until the end of the sprint and you are not complaining about it. Pointing the finger or making a drama out of this situation is not ideal, but ignoring it and making everything possible to finish your work in a time record is not helping you. Talk to your team, find together some ways to avoid having the features given to you to be tested so late in the delivery process.

▪️ Specifications are not clear and you have to test the features based on these. Don't make assumptions with regards to specifications. Rather than making assumptions, get the courage to ask all the questions, with the risk of you looking vulnerable, just to be sure you're testing what is needed to be tested.

💌 This letter is for you, my dear tester, and for the silent tester I used to be too years ago.

Photo credit: Álvaro Serrano on Unsplash and James Pond on Unsplash