Wednesday Wisdom - Wipe Out Testing Myths!

“If you could magically eliminate one common widespread misconception about Software Testing, what would you wield away and why?” :thinking:

4 Likes

Only one? That’s a hard choice!

I’m torn between two options:

“Anyone can test” also known as “Testing isn’t a technical activity” - I’d nuke this one because it devalues our specialized and technical skills. Being able to find a problem and narrow down possible reproduction paths to the simplest possible is absolutely a technical skill, as is recognizing potential problem areas in the first place. So is performing maintenance on dedicated test servers, installing test software, and pretty much everything else we do as part of our jobs.

“Every test can and should be automated” - No it can’t and no it shouldn’t. What sensible person spends months setting up an automated way to check that a printout looks right when it would take longer than the likely lifespan of the software to recoup the time when testing is a matter of hitting the print button and eyeballing the printout? Just automate sending the thing to the printer and use automation to test the things that will take forever to test without automation. Things like checking the accuracy of tax calculations, or running the application for 6 hours straight while monitoring the memory usage, or generating 500 new products for a web store.

I’ve done a lot of testing of software interfacing with physical equipment, and I can promise you, automating turnstile management software is not something you want to do. Automating RFID-controlled lockers is even less appealing.

3 Likes

That QA is a lesser activity. A nice to have. That QA is where failed developers go or where junior developers start. But most of all…that QA doesnt add to the bottom line of a company. Yes our contribution isnt a direct line to black numbers on a PL report that execs can easily digest; so we must find ways to demonstrate the value we bring with nice, broad crayon lines. This is something we havent done very well. And it has resulted in Developer-centric organizations continuing to promote the misconceptions about QA. And then making it a self-fulfilling prophecy by under-resourcing and even isolating QA from those positions of influence. I want to be clear, it isnt an organized or intentional effort. Its just a continuing. self-propagating cycle.

How do we change that? I dont have any easy answers. If there were someone else would have loudly promoted those answers. I think one way might be to find ways to cost defects. Someone may be doing this that Im not aware of, TBH. But I explore the idea of attaching costs in terms of labor and lost revenue to defects based on where in the SDLC they are identified and then fixed; with production issues being the most expensive, obviously. I say all of this being aware that there are likely unintended consequences of such an effort :smiley:

3 Likes

Great question.

I enjoyed what @cakehurstryan recently shared:

  • That 100% test completion means 100% system coverage. This leads to false confidence that testing has “caught all the issues” and is safe.
  • That testing, especially non-functional, comes at the end of a project. This leads to not having enough time to actually resolve issues that are found. (Are you really going to rearchitect the whole system if you find performance issues?)
  • That testing is destructive and testers are good at finding bugs. Testing, more often than not, gives us information that the system works and is good.
  • That testing is a saftey net and tells us that the system is good. Testjng gives us information that informs the business and allows them to make a pragmatic system to release. (We can work to help understand that things are “good enough”’though.)

Source: LinkedIn

4 Likes

@katepaulk Great insights! It’s indeed a tough choice with so many misconceptions around. Your perspective on the technical aspects of testing and limitations of automation provides valuable depth. Each misconception has its unique impact on our roles.
Thanks for sharing your thoughts and experiences!

1 Like

@msh
Absolutely agree! Overcoming the misconception about the value of QA is a significant challenge. Your idea of attaching costs to defects at different stages is intriguing. It could be a powerful way to demonstrate the tangible impact of QA throughout the SDLC. It’s indeed a complex issue, and your perspective adds valuable insights to the ongoing conversation. Thanks for sharing your thoughts on how we can work towards changing these perceptions!

1 Like

@simon_tomes @cakehurstryan Great Insights!
Dispelling the misconception that 100% test completion equals 100% system coverage is crucial for promoting a more nuanced understanding of testing role.
Your points about the timing of non-functional testing and the positive aspect of testing providing information about the system’s functionality are spot on. Shifting the perception of testing as merely a bug-finding activity to a valuable information provider is indeed a paradigm change.
Thanks for sharing these valuable perspectives. :thought_balloon:

1 Like