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.