How To Be a Bold and Confident Software Tester:
“The issues are almost similar. Mark them duplicate”, says Person 1 (you can tell, it is a developer)
“No, they are not. They impact different areas of the application. Behavioral impact is different too”, argues Person 2 (of course, it is a tester)
“Your team is only interested in increasing bug count”, retorts Person 1.
“Actually, we are trying to reduce it”, Person 2 counters.
Isn’t this a common scenario in every organization?
Tester: “What will happen if I enter special characters in the field?”
Developer: “But client has asked to not enter the special characters”
Tester: “But it does not give any validation message or restrict me when I enter special characters”
Developer: “I need to discuss this with the product manager. The implementation is done as according to the client’s requirement”
Tester: “I don’t think there is anything to discuss. If something is not user-friendly or implicit, it needs changing for good user experience”
Developer: “You continue testing. I will discuss with it the Product Manager. Let’s ignore the case for now”
For the most part of my career, I have been arguing to make my point. It makes me think, why is the industry so rude to its software testers?
Let’s say, in the manufacturing industry, if someone observes and reports a malfunction, will the product ever go into production?
Why is it not same for software too? Maybe, it is the nature of the industry and its dynamism.
But again, as a tester, you have to be bold to ask a question, to raise doubts, to convey your point and sometimes just to start the conversation.
As I always say, software testing is a tough job as you have to be a good communicator, a good reporter, good analyzer, good hunter (bug hunting of course), a good team member and ultimately a good tester.
That old era, where all the test cases were documented and tested is over now. Demand for test idea generation and quick decision making is needed. And for that, the tester needs to be bold now.
We cannot get into a shell, test as per the document, and provide a report of Pass/Fail.
We should contribute to product delivery. We should consider expected and unexpected user requirements, we need to discuss every possible outcome of an implementation and we need to test with a user’s eye.
It is important to be bold, take risks and be creative with whatever you do.
#1) Find clarifications instead of making assumptions:
When you are told that knife is to cut vegetables/fruits, did you try to cut paper? What happened? What made you try it?
Ask questions. Ask them early. Don’t quantify your questions as important or not- A question is a question. A tester needs to know how a product will and will not work so you can test it both ways before marking it “Tested”.
#2) Think out of box and don’t worry about sounding silly:
Have you ever had basil leaves in tea?? Do you know it can cure a cold? What if no one ever thought of adding basil leaves to tea? We would have missed a wonderful medicinal flavor.
Be a thinker. Think deep. Understand algorithms. Use Mindmaps. Whatever helps you understand the application deeply, try it.
Thinking and learning something new should be on the list of every tester’s diary. This helps generate test ideas.
#3) Don’t see developers as enemies. Be friends and work as a team:
Initiating communication is the toughest thing in the world and that too when you are trying to convey something negative. But as a tester, you will have to learn to communicate. You will have to be open to understanding other’s opinions and viewpoints.
In most of the organizations, developers and testers see each other as opposite teams in the game of Kabaddi, trying to pull each other at the boundary line of frustration.
Let’s change this for a change.
Rather than jumping on the bug you had reported, ask the developer – in which situations, in which technologies, in which coding standards, same kind of issues can be expected.
Share a cup of coffee with a developer and you will know that he/she is too going through same frustration, as yours.
Always remember, development and testing are both mandatory activities of a project life cycle and none of them can be ignored. Working as a team definitely lessens the internal issues at the project level and helps in delivering successful application/product.
#4) When it comes to quality, understand that you have every right to jump in if you are not satisfied:
As a tester, that is what you are supposed to do.
If you have reported a critical but randomly reproducible bug and development team asks you to ignore it, you can fight for it. After all, you are the gatekeeper and you are trusted for quality. You cannot compromise with it.
Be brave and communicate your concerns. Argue, involve other people to convey thoughts, be positive but never compromise on quality.
#5) Don’t underestimate your self-value. Consider yourself as an important part of team:
This applies to freshers or trainees. As I have been saying, it is not the number of years of experience you carry that matters. It’s all about what you contribute.
Never think that at a lower level of experience, you cannot discuss or ask. Be brave, attend meetings, and ask management to make you a part of discussions, seek clarifications, make efforts to deliver the best and shine.
About author: This inspirational article is written by STH team member Bhumika.
Do you think to be brave as a tester helps?
I certainly think so and would love to hear your opinions. So pour in your views and comments. We would love to attend to them.