• info@helpingtesters.com
  • helpingtesters

10 Software Testing Myths

software testing myths, software myths, manual testing concepts, software testing techniques

In all previous articles, we have talked about different QA practices and roles played by Software testers. There we mentioned the characteristic efforts that different type of testing demands. However, in this article, we would be talking about 10 different software testing myths that persist in the QA practices and general testing.

When people from other IT professions talk about a software tester’s role, they narrate experiences that they personally feel or what they have overheard from other professions. Some facts are true, while others are a Software Testing Myths. In this post, we would bring into limelight the different myths regarding software testing.

 Software Testing Myths 1 – Software Testing is an Expensive Investment

While outsourcing any project, clients often prioritize development over testing. In such projects, development is provided priority, and very few or no testing resource are allocated to the project.

Clients feel that developing a new product or adding new features to an existing product is way more important than allotting resources for testing the same product

Reality – The only apt response for people who share such mindset is, “It’s better to be safe than sorry”. Testing helps in unraveling underlying defects and issues that can possibly show up when the project is deployed on the production environment. Under worst case, such issues can hamper user experience or restrict the user to successfully interact with the application.

Such scenarios would lead to a forceful rollback of the application. If application testing is introduced early in the development cycle, it would not only make the application sturdy but also eliminate the chance of any major defect slippage during release.

Software Testing Myths 2 – QA Team is Responsible for all Defect Slippage

After QA provides final sign-off, the build is sent forward for UAT. If the build doesn’t receive a positive nod and comes back with a few defects, QA team being the gatekeepers are deemed responsible for the defect slippage.

Reality – In most projects especially Agile, a stable build is handed to the QA team pretty late, and close to the project release date. In such a short span of time, QA team has to test every deliverable, validate test cases, log defects and perform regression testing.

At the same time, various bug fixes are provided to the application in the form of patches, which are also retested. After all positive and most of the edge & negative scenarios are tested, QA team provides project signoff. Handling all these activities within such a short timeline is a challenging task and in some cases might even lead to slippage of few test scenarios.

Under such circumstances, the whole team, and not the testers alone are responsible for the missed issues. Such issues can be caused by not only missed test scenarios but also from last minute change requirements, miscommunication between client and offshore team and also due to poor management.

This Software Testing Myth is still prevalent in a lot of projects, and testers are blamed for missed defects. To bring the reality into the light and eliminate this misconception, testers must understand their role and make a stand to handle production or UAT hiccups together at a team, and not take the blame on their own.

Software Testing Myths 3 – QA Team’s Job starts when Product Development is completed.

As the primary objective of testers is to find and log bugs for a current build, they can start their work once complete development is completed is a common Software Testing Myths.

Reality – Every project starts with requirement gathering and by discussing the features to be developed with the client.

During this phase, QA team is involved and helps pinpoint the areas which might be affected with the current functionality. Discovering such loopholes at an early stage is only possible with the involvement of testers. It saves the complete team a lot of time and at extreme cases might force the client to change the complete functionality.

Also, when developers are busy developing the application or feature, testers plan and create test strategies to effectively drive thorough testing of the application. Thus, the involvement of testers is recommended throughout the software development lifecycle to ensure proper delivery of the application.

Software Testing Myths 4 – Once a Software is Tested, it can be considered free of all Bugs

Once testing team provides thumbs up for a build, it implies that the software is devoid of any issues.

Reality – No software system can ever be free of bugs. Even big companies like Facebook and Google provide bounties for users who are able to successfully identify vulnerabilities in their software application. The reason a software can never be devoid of bugs even after it goes through rigorous testing is due to the presence of numerous edge scenarios and the presence of different layers through which the software communicates with the end user.

Even after all logged bugs are re-tested and complete regression testing is performed on the most stable, there are chances of bugs being discovered during User Acceptance Testing or after the application goes live.

So the primary aim of the complete testing team should be to ensure that the application strictly adheres to the business requirements and no urgent/ high priority bug slippage occurs after release.

Software Testing Myths 5 – Anyone and everyone can Test Software

To become a tester, as programming knowledge is not required, anyone can become a software tester.

Reality – Testing an application is not an easy task. A tester has to understand the project requirement clearly.

Once the requirement gathering has been done, the testing team has to create relevant test cases for the different scenarios present. Also, detailed test plan has to be created so that all testing methodologies are handled properly. This requires ample expertise and in-depth project and QA knowhow.

That’s not all, testers do require programming knowledge. There are certain testing disciplines which demand the use of one or the other programming language. In order to perform automation or rest API testing, prior knowledge of programming language is a must.

Software Testing Myths 6 – Testers are not well Paid

Developers are paid way more than testers

Reality – There is no concrete proof to support the fact that developers are paid more than testers.

The pay scale of a developer or tester strictly depends on the type of project and the IT company the professional is in.  There are certain projects where the necessity of Qa is so important that they are paid way more than the developers.

Projects which have such strong dependency on testers are banking related and financial projects. As we have already explained in one of the previous articles the pay scale of a tester depends on their personal expertise and the relevant years of experience.

Software Testing Myths 7 – Only Testers are responsible for the Quality of a Product

As every project deliverables scrutinized by the testing team the only are responsible for the quality of the delivered product.

Reality – When a software application is being developed by a team, all team members are responsible for its quality.

During the application software development says all team members are considered to be the sole owners of the project. For this reason, the testing team alone is not responsible for mandating the overall quality of the product. Each team member should take ownership and responsibility to deliver a robust and functional product to the client.

Software Testing Myths 8 – With the help of Automation Testing every piece of the Application can be Automated

As Automation Testing doesn’t require much manual intervention complete testing of the application can be achieved through automation.

Reality – It is true that automation testing can help reduce the effects of manual testing, but it can never eliminate manual testing completely. There are a number of modules in an application that requires manual intervention and required in-depth analysis. 

Even though certain complex logic can be handled in automation scripts but there are certain portions which would definitely require manual input. For example, while testing a user interface all parts cannot be automated. Even though image comparison can be achieved through automation there are certain aspects of the application which can never be handled why automation.

Also converting Complex manual test cases to automation can take up enormous amounts of time which can easily be accomplished by simple manual testing. So even though in the near future scope for automation testers might increase tremendously but the dependency of manual testing can never be removed completely.

Software Testing Myths 9 – If QA team is involved in Project, Developers need not Test the Application

As testers would be testing the software eventually, the involvement of dev-testing is not compulsory.

Reality – All developers post development write unit tests and integration tests to test their code.

But there are scenarios which get missed by these tests. Also, as coding is done by the developers, they grow a certain attachment to the code. This prevents them from getting hold of any major defects while creating the test cases.

For this reason, it is mandatory that developers run a sanity test to ensure that the development is done strictly adhere to the requirement and doesn’t create any major issues. Even though developers might not get hold of quality bugs as the testing team would, it is mandatory for developers to strictly test the functionality before handing it over to the QA team.

Software Testing Myths 10 – The only role of the Testing Team is to find Bugs in the Application

The primary role of the QA team is to test the application thoroughly other roles and responsibilities would be handled by the respective members of the team

Reality – Developing a complete application is a combined process. Especially in Agile projects all team members expected to work as a single entity. For this reason, every team member’s’ roles are interdependent.

As testers have thorough knowledge about the project it is essential for them to be part of requirement gathering process. That’s not all testers can also provide design decisions and question design implementations. Thus the involvement of testers in different processes not only improves the overall process but also adds value to the product under development, so tester only finds bugs is a Software Testing Myths.

About the author

arindam bandyopadhyay author

Arindam Bandyopadhyay is an automation tester with over 5 years of experience in software testing. While during the day he juggles between Eclipse and spreadsheets, at night he lets his fingers do the talking as he writes about anything and everything his paradoxical mind desires.

Leave a Reply

Your email address will not be published.

Recent Posts