I stirred up a bit of controversy on Twitter by asking for unpopular opinions on software testing, and unsurprisingly, the community had some pretty hot takes! While I asked this some time ago, it appears that these takes are just as relevant today.
Trish Koo says “You don’t have to argue with people all the time to be a good tester”.
As testers, we are often thought of as the bearer of bad news and have accepted this as part of the job. We often find ourselves fighting for features and fixes in the name of customer advocacy. It doesn’t have to be this way. The best testers are the ones that people want to invite to the meetings. The best testers realize that their job is so much more than simply finding and logging bugs, as pointed out by Jason Phebus.
In fact, the best testers have not only found a way to become a part of the team, but have gotten their teams to realize that testing is a team sport.
Speaking of team sport, this one is from a developer who says “If you don’t start with tests, the design is probably garbage. I can’t think of any APIs I am responsible for and satisfied with that didn’t start with docs and tests”. This developer gets it! He understands his responsibility for quality even as a developer.
But I also often encourage testers not to leave the testing solely to developers during the design phase. As Jason Phebus said in the earlier tweet, logging bugs after the fact is the least interesting thing about testing. Get involved in your design meetings and help the team spot flaws in their approaches before a single line of code is written. Now, that’s powerful!
Let’s head on over to test automation…
Paul Grizzaffi says “A failing automation script does not necessarily mean that the script is wrong, horror of horrors, the script may be accurate”.
If you immediately question your test script when it fails, it could be a sign that you are not confident in this test. A lot of times people are not confident in the tests because they barely understand what it is that they’ve coded. As the director of Test Automation University, I have a lot of people ask me about learning Selenium or Appium, or some other automation tool. I get it, you need to learn the tool to be able to do the job. But can I tell you that you’re shortchanging yourself? Automation development is so much more than a tool. Learn the craft, learn the strategies, really learn to code! That way, when things fail, you know how to properly analyze what’s going on.
Just think about how much more value you can add if you’re truly code literate, as pointed out by Amber Race.
Even if you’re only able to read it, you now can understand much more about how your application works and sniff out poor coding practices that can lead to bugs.
And if you are writing code, you don’t have to stop just at automating tests. You can contribute so much more to automating processes, increasing test automatibility within the product itself, and even fixing bugs that are found.
You may be thinking “well Angie, if I’m doing all of that then I’m doing the job of a developer”. Yep, you absolutely are.
As Justin Ison so accurately says, quality managers expect you to test the entire site, write detailed bug reports, learn to program, automate all test cases, and setup CI/CD for half the salary of the developers creating the bugs!
So, to all of the quality managers and executives reading this, listen to David Burns and pay your testers the same salary as your developers, if not more!
Because “a tester’s mindset is the most powerful thing in computing”, says Orandi Harris. Know this, believe it, and act accordingly.
