Demystified: 5 Popular Software Testing Myths

Dearly beloved, we are gathered here today to demystify some of the popular myths of software testing. This article is based on personal experiences collated from software testers around the world. Let’s dive right in!

1. “Aren’t you people just clicking buttons?”

Before I even address this, below is a typical scenario in an Agile Sprint Planning;

Dev: I need 3 story point for this task

Tester: I need 2 story point to test this task

Everybody: ahn,ahn are you not just clicking through

Tester:

Let’s look at it this way — if it takes a Developer two days to finish a task based on the acceptance criteria listed by the project manager, testers are required to create a robust test script, think of edge cases and test across multiple devices and browsers -most of the time. And this is minus the back and forth that might ensue between testers, developers, PMs and even network managers. Trust us, this can be time-consuming.

2) “Testing starts after development task is done.”

Hmm… the thing is, testing is supposed to start as early as the requirement gathering phase. Testing is included in the Software Development Lifecycle but there is also a Software Testing Life Cycle as seen below;

Starting tests early helps to prevent the back and forth that happens at the end of development. Quite a number of testers are guilty of not pushing for testing early in the project, and end up rushing to meet up with deadlines. Starting tests early does not just save time, it helps to create a better understanding of the project, thereby creating a diverse perspective for tests.

“Quality is the ally of schedule and cost, not their adversary. If we have to sacrifice quality to meet schedule, it’s because we are doing the job wrong from the very beginning.” -James A.Ward

3) “Send your test report, let us know our application is bug-free…”

“The only certainties in life are death, taxes and bugs in code.”-Anonymous

Software testing will always prove the presence of bugs not the absence of it. Testing is to make sure the software satisfies the given requirements and to make sure we don’t push out a ticking bomb in place of a software. Some bugs remain in software forever and even a mega microscope would not find them

4) “Your task is monotonous, you must be so bored…”

PM: Hi QA, we need our regression report. When will you be done?

QA: Give us about 20 minutes.

PM: uhn?

QA: Opens IDE, clicks run project as Test suite

*sips coffee*

QA: Hello team, attached is a copy of the regression test ran.

Truth be told, the monolithic nature of a job can’t be completely removed, however, it has been significantly reduced, thanks to automation. It is also very important we remember that different things drive different individuals hence, the word boredom is relative.

Testers are highly inquisitive people, they want to know what makes what tick. Finding things where they are not supposed to be to us equals the joy of a crush finally texting back.

We be like:

5) Developers and Testers have the worst relationship

Our relationship can sometimes be likened to a love-hate relationship. We can all agree that it does not feel nice being judged. The truth is, we testers table issues to developers in a judgy manner, like “what the heck did you code???” Testers are the major cause of this misconception. We most of all ought to understand what it means to have our works undermined.

We must be able to draw a fine line between judging other people’s works and creating an understanding that we simply want our works to be the best it can be. We do more than Quality Assurance, we also provide Quality Assistance.

If there be anyone who does not agree with all that has been explained, speak now or forever hold your peace.

Shalom