By Heather Reid
There have been many posts over the years about the Falsehoods Programmers Believe, so much so that there is even a Github repo dedicated to it. Programmers are not alone in the falsehoods they believe, however, the software testing and QA profession have a few of their own, as evidenced in one of our popular discussions on The Club, our software testing community forum.
We thought it would be interesting to revisit this discussion to see if anything has changed or there are some more additions. This is a short summary of the discussion on The Club. Feel free to read this summary or go to the topic, and join in the conversation.
What Falsehoods do Software Testers Believe?
About Developers
The top voted response to this post was “Developers can’t test”. While some can laugh and talk about how “developers write unit tests so isn’t it obvious that they test?”, there are more who enter a team and panic about developer to tester ratios because they think “Developers can’t test”. However, developers can and do test, be it on the unit level, the idea-generating level or beyond. Lisa Crispin wrote a really useful article about pairing with developers for testing which would be a great way for those who believe this falsehood to see the type of testing that developers do.
Some testers also believe “There is no point in respecting developers. They cause all of the problems.” or that “Developers create bugs”. Folks believing these falsehoods will sometimes look for help amongst their fellow testing peers and be surprised when they receive suggestions to have a conversation with the developers because many also think “Developers don’t like testers”. Which may be better rephrased as “Developers don’t always understand testers or why they are asking questions” or “Testers don’t always understand developers” no matter which version you prefer, effective communication can really help with understanding as can having empathy for other roles.
About Testing All the Things!
“You have to test everything” because “It is possible to test everything” and “You can test everything completely.” So many testers and QA professionals burn themselves out believing these falsehoods. This, to an extent, does tie into the falsehood mentioned above that developers can’t test and so the tester or QA team member must be the only person who tests.
Another relatively common falsehood is that “You need specifications or use cases to be able to test something.” You don’t. You and your team can start testing before any code or specifications are ever written. You can test ideas and think about user journeys. You can explore the existing product if there is one with different user hats on. Is it accessible? Is it secure? What improvements might you suggest that aren’t in the next release or the backlog? Is there a device/browser that you didn’t get to test on yet but you’d like to? A lack of specifications doesn’t restrict you, in fact, it may open more doors. Check out “Testing without requirements” for more insights.
About Best Practices
If I had a euro for every time I saw a question asking about best practices because “There are best practices that apply in all situations”, I’d be doing pretty well. I’d probably be doing even better if I had a further euro for every time someone replied with “It depends”. The thing with software testing and development is that there is no one size fits all or set of best practices that can be applied in a blanket across every organization. Every situation, company and team are different. It’s what gives us such a variety of products out there and so makes it difficult to define a best practice for any one thing.
About Automation
Forever a hot topic in the industry, automation generates its fair share of falsehoods for testers to believe. The hottest of which is probably “You can automate all your tests.” and so “The future is that all testing everywhere will be automated and all manual testers will be unemployable.” or “You need to be able to write automation to be a good tester.”
There’s a lot to unpack here! The first and easiest to address is that no, in fact, you cannot automate all of your tests. You can automate a lot of things but certainly not everything. For more reasons as to why this is the case, check out “What’s the difference between a human test and an automated check?” There will always be a need for testing that isn’t automated for reasons outlined in “Why will testing never just be automation?”
About Detail Orientation
A contentious falsehood: “Testers need attention to detail”. Contentious in that many believe attention to detail includes spelling mistakes or incorrect word usage. I’ve had many heated discussions with people who felt all spelling mistakes on the team should be captured by the tester but that’s a story for another Club post or article.
The person who put forward this falsehood followed it up with “testers need to be aware (spatially and otherwise) - attention to detail is less relevant if you can just see that something is different - you have time to work out what”.
About Releasing
Another falsehood that can lead to burnout; “You make the release decision” as the one and only gatekeeper on a team of many people, you alone hold the key to the release gate. Read more from Lisa Crispin discussing whole team testing to explore and understand why this is a falsehood.
“You can’t release something without testing it”. As mentioned previously, it isn’t possible to test every possible permutation of your system. So we can and will release software/features without testing whether we realise it or not.
About Themselves
“If a serious defect reaches production it’s all our fault and we’re useless.” I’m guilty of believing this myself on numerous occasions. If you find yourself thinking about or believing this falsehood, ask yourself “How many people did this bug pass before it got to production?” This is not a question designed to point the finger of blame elsewhere, rather it’s sharing the ownership of the issue with everyone on the team.
You can’t test everything, other people on your team can test and other people on your team missed this too. Is it a rotten feeling? Sure it is, but it should not be a feeling that rests solely on you and eats you for days/weeks/years to come. Kate Paulk backs this up in “Ten Reasons The Whole Team Owns Defects”
Join The Discussion
Have you thought of more falsehoods or follow-up discussion to the ones mentioned above? If so, you can head over to The Club, and dive in! We learn by listening to and sharing with others in the community and there’s no better place to do that than The Club. Browse past topics and create new ones. Access to The Club is free with a Club level Ministry of Testing Membership.
Author Bio
Heather is currently the CommunityBoss at the Ministry of Testing. She was previously a developer but testing and helping the software testing community is her passion. Heather joined the Ministry of Testing after co-organising TinyTestBash Belfast and wowing the Ministry of Testing with her drive and passion for helping the community. This all started when Heather discovered the Ministry of Testing through TestBash Brighton in 2016. When she's not testing she's usually exploring or working on restoration projects. You can find Heather on Twitter where you will also find a link to her blog.
