9 Common Software Testing Myths and Facts

This article is intended to make our readers aware of some of the most common myths in software testing vs reality. Let’s get started. 

Having been in the QA field for 9 years now, I have seen that some people tend to generally stay away from a testing job. They feel inferior and have a lot of negative thoughts running through their minds.

I would like to share my thoughts and experience and address some of the common myths that people have.

Sometimes, for various reasons, there are a lot of expectations that we set for ourselves but aren’t always true. These expectations often lead to a lot of disappointment and distress because none of them are going to be met, as they weren’t valid in the first place.

Myths in Software Testing vs Reality

Today we want to list a few of them and also start a forum for discussion on what other testing professionals think of this topic.

My personal experiences in the following areas tell me that I am on to something. But I would seek all of your opinions all the same. I invite you all to participate.

9 Common Myths About Being A Software Tester Vs Reality

Let us begin.

#1) Testers get involved ONLY post-development in the project lifecycle

This is one of the biggest myths. If it becomes a reality, the project has huge problems. 

• Involving QA at a later stage is a big risk to quality and the schedule of the deliverables.
• Testers need an equal amount of time as developers. This is to understand the requirements, analyze gaps, prepare their deliverables, plan and execute tests.
• If testers are involved at the later stage of the project then they rely on the developers understanding and follow it while testing the product. In the end, it’s very unlikely to improve the quality of the deliverables in the end.

Instead, a test team must have their own mindset, understanding, analysis, time, and involvement from the beginning.

This will not only help the QA team test in a better way but also lets the entire project team implement better quality assurance. Many organizations realize this and include their QA teams from the project’s initiation.

#2) Testers will not become Project Managers

Many think that if you are a tester, you do not have a career growth in the management side. However both are mutually exclusive. To be a manager you need to acquire skills like people management, cost management, time management, etc. As you can see this has nothing to do with Testing, Development or anything else technical.

The project management skills have to be developed separately and anyone belonging to any technology or stream can do that. Therefore, being a tester does not deter project management pursuits. It is an independent field and anyone with a keen interest can make it.

#3) Reporting to Dev lead is a “block” to a tester’s career

Ideally, there should be separate verticals; both Dev lead and QA lead should report to a PM. But sometimes there might just be a Dev lead for both Dev and test teams and we have to report to someone who might not know about testing in-depth. It is not the best situation but it is definitely not the end of the world.

As long as you are doing your job right and being patient with the lead to help them catch up with testing practices, you should be good and will not have a long-term negative impact on your career.

#4) People with weak coding skills are assigned to testing

The most common myth about being a tester is that testers are not good coders. In fact, testing involves coding too, in most cases.

• Testers do write complex SQL queries to validate data or to create test data in case of ETL testing/data validation.
• Testers do convert the code written in one DB to another in the case of migration testing.
• To automate testing, you are required to write scripts in JAVA/Perl or other coding languages.

So, there is really no weight to this opinion.

Also read => Top 5 Things a Tester Must Have to Excel

#5) Testing is clicking on random places

A common perception is that testing is just clicking on UI randomly and tracking details in excel or other documents.

The reality is that testers perform very well-defined test steps to ensure that the UI/APP is working in exceptional cases as well. So, it is the vision that counts.

Since a user does not have boundaries on what they can and cannot do, the same goes for testers. This is why it is important to explore the UI, which might look like lots of random clicks. Only we testers know that there is a method to this madness.

#6) Testing is just documentation/filling excel sheets

Firstly, let me strongly say this, documentation is the job of everyone working on a project. A precise, complete and accurate document gives a foundation and historical evidence about the project.

However, for testers, documentation is more important because the deliverable we create is not a program or module, but it is an assured quality which takes a solid shape through artifacts. The Microsoft Office suite is the go-to choice for most teams but to take it to the next level, use test management software.

 #7) Testers have a low pay scale

If this is happening to a tester then he/she is in the wrong place and might need to consider a change. Having said that, pay depends on a lot of factors and to say that being a tester is the ONLY reason why you will be paid less, it’s not true.

For more information and some quick comparison, ccheckpoint#5 here => Who Earns More, Software Tester Or Developer? Let’s Find Out By Comparing Salary

#8) Testers do not get fame

Testing sometimes seems like a “thankless” job. Understand that it is nothing personal. It is sometimes a matter of the company’s culture on how they value their teams.

Try to stay positive and let your work speak for itself. Try not to expect medals and awards for doing your job. Agreed that things are easier if the team and the clients appreciate the QA teams, but if they don’t, it does not mean we should undervalue ourselves.

I worked in both extremes and thoroughly enjoyed working with clients who knew what QA and its importance are.

Recommended => Is Software Tester’s Job Really a Low-profile Job?

#9) Testers delay project delivery

Irrespective of starting out in parallel with the Dev team, we still have to wait until the development is completely done to start testing. Following that there is bug reporting, correcting, retesting, etc. This gives a superficial impression that testing is dragging the project on and on.

The problem does not arise with teams that have pre-planned test cycles. So, testing does not delay projects but incorrect planning and unreasonable expectations do.

******************************

Update:

3 More Major Misconceptions that Testers Need to Dismiss

Misconception #1:

Automation testers do not have to bother themselves with manual testing

Nothing could be more far-fetched than this statement. Automation testing, as we have stated repeatedly on STH, is also testing. It only differs in the area of how testing is performed. It should not be forgotten that automation testing always succeeds or follows the manual testing process. Sometimes, automation testers and manual testers are the same. However, not all projects are automation projects.

So, we are testers first, and it is important to remember that before we make the specialization our main area of focus.

Having worked on one automation project does not and ideally should not ruin us for manual testing.

Manual testing is a skill that we all build on; it is fundamental and our foundation. Automation testing is great. It is the closest thing to magic we have in our QA field. But considering one to be inferior or superior to the other is not the attitude we want to see in the field.

Automation testers perform a manual testing role in some projects and manual testers perform automation in other cases. They are not mutually exclusive. In fact, the differentiation of testers as manual testers or automation testers is quite disturbing. Let us not encourage this culture.

Misconception #2:

Test leads do not ‘test’

I had a colleague at a client located in the US, where we were both handling a module each in a project. He had 3 offshore resources reporting to him and whenever he made effort estimates or test plan, he always did so taking into consideration only 3 people for test design and test execution.

When this came up in an audit meeting and he was asked why he was not counting him (my colleague) to be involved in these activities, his answer baffled many of us. He thinks it is beneath him as a test lead to write test cases and execute them. He would not bother with those tasks because he thinks they are “lowly” and that he would only overlook or coordinate the process.

What followed in the meeting is not relevant to us, but let me tell you that he is not alone in feeling that way.

The reality is that the industry standard for coordination efforts is just 10%. Test lead is also, always a part of the QA team, which makes a lead responsible for contributing to the testing activities. Agreed, there are other tasks as well.

So, a percentage of the QA lead’s bandwidth, however small it might be, must go towards testing activities. We have to prepare ourselves to be a tester doing all the tasks you would normally do as a QA team member for the rest of our careers, or it might be time to consider a switch in fields.

Also read => Test Lead Responsibilities and How to Manage Test Teams Effectively.

Misconception #3:

Testers tend to doubt everything and that they are the forever sceptics in the IT industry

Imagine how difficult life would be if we did not trust anything. A skeptic’s life is the toughest. If it were true that we doubt everything – we would even be questioning the very existence, implementation, and efficiency of the software – which means we are working while believing that the product is useless.

Do you think that’s the right attitude? Can we really do justice to spending a good amount of time working on a software system while we think it is absolute garbage? I don’t think so.

When in need of some guidance as to what kind of mindset is best, the quote by a former US president, Ronald Reagan comes to mind –“Trust, but verify”. Even though the context is completely different, this hits home like nothing else would.

Therefore, contrary to popular belief, we testers believe in the software’s ability, performance, efficiency, productivity, its purpose & capabilities and we always root for its success when it hits the live world.

But we want to make sure that it is at its absolute best. We test keeping in mind that the product is great and that we need to identify and remove anything that might negatively impact an already terrific product. We believe in it and are ardent fans of it. Isn’t that true? It is for us and we are sure that it is the same for you too.

Conclusion

We hope that this article has put to rest some of the common rumors that have been going on in the IT circles about the QA community. (Just kidding :))

Be a tester if you believe in QA.

It’s an amazing job to do and you are going to enjoy it and love it.  Don’t forget that you are paid to improve the quality of the end product and for your excellent skills.

Believe in yourself and your work and accept the challenge. It’s really not everyone’s cup of tea

As we mentioned at the beginning of the article, we hope this post would be a good initiation for a long, productive, enlightening discussion on the subject in the comments. Come on, let’s hear it.

What do you think of the above list? Agree? Disagree? Somewhat agree/disagree? Let us know your thoughts in the comments section below. We would love to hear from you.