Testing Myths

I just realized that it has been little over 5 years since I wrote about five software testing myths and it is unfortunate that I still see, hear and find people arguing about some of those myths after half a decade. While there are literally tens of those myths floating around, here is my take on five of the most common testing myths that I keep hearing these days.

Be it the blogoshpere, the so called expert columns on various sites, social media discussions, tech industry journals, or casual after-lunch office gossips, these myths are as easy to to be spotted as easy it is to find bugs in a half-baked software developed by a novice programmer.

So without further ado, here goes the top 5 software testing misconceptions and myths (in no particular order) that are plaguing our modern day testers these days:

1. Software Testing is a Mundane, No-Brainer Job:

Ohh, yeah? On second thoughts, perhaps there is some element of truth to that statement. Testing can indeed be boring and feel like a mundane monotonous task if YOU ARE DOING IT WRONG! Ive seen people jump to this conclusion (that testing is boring) because they see (and believe) testing as repeatedly doing same/similar tasks over and over again.

Going by that logic, programming, web designing, analysis, accounting, banking and any day-to-day vital activities like eating, sleeping etc can also be considered boring if you just look at the repetition part. Moreover, do you stop eating and sleeping because it is a repetitive task that you are needed to do daily? Or do you change your food menu and sleeping habits when you feel bored?

But if you are really a good tester, then you would probably look at testing as an information gathering activity done with an intent of exploring and discovering answers [NOT just flaws or bugs in the software] to questions that nobody had asked before. To achieve so, you would need to study, explore, observe, analyze, use the software to be able to evaluate it. Does that sound boring to you?

If you ever get bored of testing something, don't blame your job. Rather blame yourself and CHANGE the way you are testing, thinking and devising your test ideas and before you know it testing the same software would start feeling so much of fun, once again.

2. A Tester Should Be Able To Test Everything:

Yes, as a tester I can of course test everything provided as a project stakeholder you can provide me with indefinite supply of resources, infrastructure, budget, time and what-not!

It is foolish to expect that a tester (or a testing team) can test each and every test scenario, theoretically possible within their given time-frame and with the supplied resources. While a good tester would generate critical test scenarios and prioritize them and test, it is impractical to hypothesize that it is possible to test ALL those scenarios. Wouldn't that be same as expecting'testing can deliver a 100% bug free product'?

The reasons why this is not possible can be many -- lack of enough time, lack of available infrastructure to test something, vastness of all permutation and combination that can exist and so forth. It is an inherent quality of software testing that it can show that bugs exist, but not that bugs doesn't exist.

Lets take a simple example. We all know that life critical systems like instruments used in medical facilities, airplanes, space ships etc go through a stringent set of testing procedure to ensure nothing goes wrong when they are operational. However, can the tester(s) testing a flight actually predict and test considering the actual air pressure, altitude, number of passengers and crews, total load on the flight, wind speed, temperature etc, on any particular day? Can their simulator simulate any random days environmental and other variables that the flight will have to take when in production?

3. A Testers Job is to Find Bugs:

I don't blame you if you don't see how this is a myth or misconception -- many don't. It is easy, especial for someone who has just recently started her career as a software tester, to get confused about her responsibilities as a tester. And many often fall into the trap of believing that finding lot of bugs in the software is their prime goal.

I admit that finding bugs in the software is an important part of what a tester should do. But the story doesn't end there. Along with just finding bugs, testers do analyze the requirements, review the product architecture, provide ideas to make the product more user-friendly, validate the help documents and a lot of other things.

4. Tester Adds No Value to The Software:

People who conceive this myth often are made to believe that a testers role is strictly limited andadds no value to the product.

On the contrary, a skilled tester is often an expert of the system (product) under test. Unlike the programmers who often spend most of their time working on a very specific area, function or component of the application, the tester analyzes and understands how the entire system works from an end-to-end standpoint. Testers get a better chance to demonstrate their understanding of the product in a way that adds value to to the product.

5. Test Automation Will Eliminate Human Testers:

This is perhaps the most outrageous prediction that many so called self-proclaimed test automation gurus are making at the moment. What is even more insane is the fact that there are actually testers who are believing it!

Can test automation tools replace human testers? Id say a big NO. Why this is not going to happen ever, is simple. I remember not so long ago when the concept of Computer-Aided Software Engineering (CASE) emerged and suddenly people started talking how computers would start writing codes and in turn can make human programmers obsolete. But whether that actually happened is a matter of everyone's guess today.

Similarly test automation is never going to replace human testers, UNLESS, of course, humanoid auto-bots take over our planet one day. Until that (judgment day) arrives, we human testers will never be expendable for a very simple reason. We have something that the test automation tools do not have; it is emotions. And since the users of the software we test are almost always be humans, it is the human testers who are going to have this advantage of testing it better than any automation tools.

For instance, a tool can tell me if the fonts, color and layout of a screen is as per the test script but it can never tell me if a human being is going to find that screen pleasant enough to use.

Having said that, test automation tools are not necessarily bad for testing. They can actually be useful for testing certain aspects of testing (like large calculations, testing involving performance and load, repeated regression tests etc) that would otherwise be very time-consuming and hectic for a normal human tester. Hence, under certain contexts, automation tools can act as supplementary tools to aid human testers; NOT to replace them.