9 Common Software Testing Myths and Facts

Myths in Software Testing vs Reality:

Being in the QA field for 9 years now, I have seen that some people 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 common myths that people have.

Sometimes, for various reasons, there are a lot of expectations that we set for ourselves that 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.

Today we want to list a few of them and also in a way start a forum for discussion on what the rest of us testing professionals think regarding this topic.

My personal experiences in the following areas listed 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

HEre we go.

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

This is one of the biggest myths. If it is 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 the 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. And 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 QA team test better 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. But 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 in this world belonging to any technology or stream can do that. So, being a tester does not encourage or deter project management pursuit. 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 testing in-depth. It is not the best situation but 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.
• For automating testing, it is 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 at random places

It is a common perception 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 assure 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 a 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 at 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 enjoyed thoroughly 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.

This 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 stated repeatedly on STH, is testing also. It only differs in the area of how testing is performed. It also should not be forgotten that automation testing always succeeds or follows the manual testing process. Sometimes, automation testers and manual testers are the same. Also, 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 the 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 actually 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 to feel 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 yourself to be a tester doing all the tasks you would normally 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 Team Effectively

Misconception #3:

Testers doubt everything and that they are the forever ‘skeptics’ in the IT industry

Imagine how difficult life would be when if we did not trust anything. A skeptic’s life is the toughest to live. 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 think not.

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 actually 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 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 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, 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 great initiation for long, productive, enlightening discussion on the subject in the comments. Common, let’s hear it.

What do you think on the above list? Agree? Disagree? Somewhat agree/disagree?