7 Myths About Software Testing

By Gaurav Singh

Hello there!

In software engineering, the role of a tester has a lot of myth and stigma attached to it. This post aims to dispel some misconceptions and provide an inside perspective from someone who has been through the dark woods of software testing.

Who is a tester, you might ask? Well, GOJEK’s India head has some profound thoughts on the subject:

A tester is a cross between a developer and a product manager with a healthy dose of paranoia — Sidu Ponnappa

With that established, let’s go bust some myths:

1. Manual testing is non-technical and easy

As harsh as it sounds, this is where most of the stigma about testing as a skill originates. People who do manual testing are considered less technical, as most cases require them to black box test the application using the UI — like an end user would do.

Is this true, though? 🤨

Well, yes and no. Testing can be as technical as the individual desires, if they have the right mindset to dig deeper.

Testers do not have to restrict themselves to just UI testing. There are many different areas where a tester can add value to app development (API/DB/Contracts/Integration/Unit/Performance/Security) and so on.

All of these areas require someone to understand how the nuts and bolts work, and find ways to identify gaps and ‘break’ the system.

2. A tester is born with special skills and is the ‘ONLY’ one who owns quality

This one bums me out — not so much when it comes from devs, but from testers themselves.

Throughout my career, I have faced situations where devs who are not motivated enough to test their own code would throw every small change to the tester to verify. More often than not, the tester would find some issues/bugs in this code. This is followed by self-validation and euphoria, and the dev and tester repeat this cycle endlessly.

Testing is not a magical skill which only a select few individuals possess or are able to master.

We are not special snowflakes. Anyone who believes this is just wasting their own time and that of their colleagues.

Developers can test code, PMs can test, and so can a tester. Anyone who has the right testing mindset and is curious about how stuff works/breaks can contribute to this effort.

Let’s take this with a grain of salt. Some activities are indeed better guided by a person who specialises in testing and can move the team towards a culture of quality. However, this in no way concludes that it is the testers who own quality.

If both devs/testers would do each other a big favour and work together, we would have much better teams and quality products at the end of the day.

3. Testing is just verifying the app from the UI

“You are introduced into a new project with no test coverage, what would be your approach?”

If you ask this question to someone who is getting started with testing and automation, chances are you would hear something like this:

“Well, I would just test and automate every case in the UI using selenium/appium or an equivalent tool.”

Did you spot the mistake in this approach?

Well, for starters:

• It completely inverts the automation pyramid. The intent for testing something should be to get quick feedback, and UI tests completely beat that intent.
• Also, this creates a dysfunctional scenario wherein someone has to maintain and debug 1000+ long-running tests that oddly, have been known to fail on occasion. 🤦‍

Yes, you can do parallel executions on a cloud provider, and throw more VM’s or containers at the problem. This does not change the fact that successfully getting a lot of value out of UI tests is a very challenging task with low ROI in most cases.

Instead, if more API, Contract tests, Integration, and Unit tests are written with some cherry picked UI tests on top, it would be a win-win for everyone.

4. Manual testing and test automation are two separate entities

There is a great divide in the testing space where folks identify themselves as either Test Automation Engineers (a.k.a SDET) or Manual Testers. Generally, automation skills are more sought after than manual testing skills (some folks even brag about it).

On the other end of the spectrum, some are reluctant to pick up automation skills.

In reality, what seasoned testers realise is:

Test automation is just a means to an end. Not THE END in itself.

Manual exploratory testing is a large precursor to automation and requires curiosity and the ability to not look at a feature/app with inherent biases.

Automation is just another tool in the arsenal of a skilled tester to eliminate repetitive tasks or delegate computations that are better done by machines. For example: would you like sniffing through thousands of lines of logs to identify error patterns? Surely, a machine can do this better.

It’s silly to think test automation kills job opportunities for manual testers, when it only exists to make life easier for them. No one person can test 100 microservices with 10 conditions every night. It’s not practical or possible.

In essence, manual testing and automation are really allies fighting the same war.

5. Test Automation is not ‘development’

Lots of testers believe they need to understand only the basics of programming to be able to succeed with test automation. As long as a tester can write crummy code that does the job and works, it is acceptable.

We don’t need patterns or clean code. A test function which is 100 LOC long is perfectly fine since we are not ‘real developers’ anyways. Right?

Wrong.

Code is code. Regardless of who writes it.

We face challenges like these:

• The act of crafting meaningful automated tests requires understanding the feature behind it thoroughly. This is to ensure we assert code at the correct level using functional or non-functional aspects. This requires sound dev skills.
• We need to write maintainable, extensible frameworks which are intuitive for others to follow, in order to allow testing efforts to scale.

Testers choose programming languages to support automation of tests and write extensible frameworks to support UI/API/Contract automation. Developing POC’s, using IDE’s, working with build tools, CI, test frameworks as well as setting up telemetry using different reporting solutions, are all activities which require skill.

These tasks are no less challenging than writing a backend service or a UI using some framework. It’s no less, and should not be treated as such.

Testers also need to understand that anything less than clean code should not be acceptable.We also need to understand sensible dev practices and patterns if the framework/harness has to scale.

Everyone is a developer and should aim have the same set of technical design/coding skills to be efficient.

6. Everything needs to be automated

A common misconception — if you have 1,000 cases asserting your app then every last one of them needs to be automated.

What people learn from experience is that every new test adds its own maintenance costs. People who have been down in the trenches know that test selection and prioritisation i.e choosing what to automate and when, is an essential skill.

This can make all the difference between successful or failed automation projects.

7. As a tester, we should be isolated from devs and should not look at dev code/PRs/Unit tests

Have you seen cases like this?

• Tester will ask devs if they are writing enough unit tests for the feature and be satisfied with just a verbal response.
• Testers rarely take a look at created code in different pull requests?
• Testing is treated as a separate discipline and feel they should test everything from outside the box.

All of these are, in some shape or form, myths or old practices which do not have much of a place in the modern era of software engineering.

Agile as a core tenet advocates for a ‘whole team’ approach wherein teams really are cross-functional. Therefore they can and should collaborate on code.

There is nothing wrong in getting code access to the app that you are testing day in and out to get an insider perspective of how it really works (or giving comments on PRs). Acts like this can help bridge the gap between dev and test. You might not understand each and every component, but you might be surprised by the value you can bring to the table with your systems thinking mindset and ability to see impacts beyond the immediate code. Devs deep in the act of creation can sometimes miss basic or edge conditions which are often better captured as a unit/integration test.

But you, as a tester, can help identify (and even fix) these issues 👍

Hopefully this post helps clear some of the myths around testing. If you found this useful in any way, share it with a friend or colleague.

Until next time, keep breaking stuff! Cheers!

250+ engineers, 19+ products. How do we keep so many plates spinning, right? Well, we hire the best people for the right jobs, and practise a lean engineering mindset. Our teams work in close collaboration across geographies to fuel the GOJEK #SuperApp. Sound like the kind of job for you? Check out gojek.jobs and come work with us. 🖖