Is it when I write detailed test plan and test case documents?
Or is it when I’m able to report hundreds of bugs for programmers to fix?
Am I effective if I can write automated checks for the team’s end-to-end regression test suite, or am I ineffective when I don’t know how to write test code?
Is my testing well done if we release projects on time but have backlogs of things to fix, or is it alright to be delayed, knowing that the team has baked as much quality possible to the software right from the start?
Am I a lazy software tester if there are no major problems to report, or am I holding the team back when I tell them that there are critical bugs in the system right before a release schedule?
It’s a given that I’m always looking for patterns, and because I see patterns I’m eventually bound to find mismatches. I find risks. It’s become a natural consequence that I find potential problems, and so I often find myself become the bearer of bad news.
But the news doesn’t have to be all bad. If I find a problem, I can probably find it’s root cause, say about 90% of the time, and if I do that fast enough, I can help the programmer create a solution ASAP. It’s the same thing with feature requirements; I can help the product managers revise them when I’m able to quickly find inconsistencies and the could-be valid reasons behind them.
And if I find potential risks, I learn why they exist. I learn something about the team – our abilities and our limitations.
Speed of feedback matters. Good communication matters. Skill and confidence matters. Learning matters. Empathy matters. And to bring out all that in a testing activity, to be an effective software tester, what it takes is the ability to focus, to care enough, in finding solutions to customer (programmer, product manager, end user, support teams) concerns.