Historically (before 15 years ago or so) software developers both wrote and tested their own code. As demand increased at Internet speed for software and apps, software companies responded with more frequent versions and updates.  At the same time users’ expectations for rock-solid releases that met their changing needs increased as well.  

Of course faster and more frequent releases created more room for error and so the need for software quality assurance became apparent in order to support the need for fast-turnaround time of software that works. And so software testing as a function and a separate entity from development to offer competent, speedy review became prevalent and a “must-have” for many organizations.  

Since then the role of a software tester has come with many misconceptions. Let’s try and get the facts straight. 

 

Myth – Testing is too expensive.

Fact – The origins of this myth lie in the very legitimate concerns of product owners with tight budgets. But what costs more money – paying for proper testing or the lost opportunities and market share created by a buggy software release? Worst case you lose customers… best case a serious bug found in production will create a fire-drill for your dev team. Since your market credibility and customer base is at stake, not to mention the prospect of your budget going haywire due to damage control at this late stage in development, it’s definitely worth the effort and investment to plan for testing your software. Notice I didn’t say cost, but rather “investment” as testing is, in essence, a huge factor in your prospects for success. 

Bugs can also slow down production as developers aren’t the best resource to uncover bugs. Developers create, testers break.  At the very least you need to execute basic QA testing throughout the development process. 

You can read more about why fixing bugs in software earlier is a good strategy at: https://airbrake.io/blog/insight/why-early-bug-fixing-best-strategy

It is more important to have the right people involved than to follow the process exactly right.”

– Rex Black

Myth – Testing is easy, no formal training is needed.

Fact – It’s generally assumed that anyone can test. That it is easy… all you have to do is “play around” in the app.  But in reality, quality and thorough software testing is very challenging.  A good tester must be adept in many arenas including having a comprehensive understanding of testing methodologies and planning strategies, technical abilities, a knack for paying attention to detail, patience and persistence, good communication and interpersonal skills, and more. The value of a tester with proper training and experience in the industry cannot be understated. Professional QA testers will find more bugs, at a faster rate, and documented in a way that they can be fixed quickly. Software testers bring to the table not only in-depth knowledge of the development process and testing methods, but also the skill to comprehend and adapt testing techniques to the business goals of the project.

 

Myth – A software tester’s only task is to find bugs… period.

Fact – Testers do not only test, they understand the development process and business goals of your software. Software testers are able to take a holistic approach to software to make sure it works as intended.  Software testers are also referred to as “quality assurance engineers” because they’re asked to focus on every aspect of the development process. While developers focus only on the detailed code level, testers look holistically at what contributes to a solid quality end-product. Software testers plan their testing strategies so their testing results in better software.

 

Myth – Testing using an Agile methodology does not follow well-defined strategies.

Fact – An “Agile” methodology relies on cross-functional teams working together in an iterative approach. Many teams purport to be Agile yet they do not implement any particular model such as Kanban or Scrum, and can therefore seem quite chaotic. In fact, there is a clear and strong Agile model and underlying philosophy, and a lot of effort goes into planning an Agile environment such as the budget, resources required and sprints. Also, test cycles have to be planned in sync with the development cycles and are a part of the sprint planning. There is a system to Agile after all!

 

Myth – Testing is too time-consuming.

Fact  – Constrained by budget and time considerations, product owners feel that testing is time-consuming. It is undeniable that proper QA is part of the development process and therefore takes time to do well, but testing by experienced professionals is much faster and yields better results than by non-professionals. In the never-ending battle between risk analysis, meeting deadlines, and managing opportunity costs, it has been proven time and again that proper and efficient software testing is well worth the cost when compared to the alternative. Testing is crucial to ensure that the product works well and is loyal to the business goals, and a well-managed development process can produce not only solid and bug-free software, but also software delivered on time. 

 

Myth – Automation eliminates the need for manual testing.

Fact – Automation testing is no substitute for manual testing; after all, an automated solution is often based on manual test plans. Plus, as with any software, an automated test only can do exactly what you’ve programmed it to do [NB: until AI catches up with us]. QA teams seeking good test coverage will always include some degree of manual testing to confirm execution results and fill in the gaps with exploratory, security, usability, and more kinds of tests. Automated testing for ensuring software quality is only warranted after careful analysis, and used as a part of a comprehensive quality approach.

“There is nothing quite so useless as doing with great efficiency

something that should not be done at all.”

–  Peter Drucker

Myth – Testing means bug-free code.

Fact – Testing merely helps identify the bugs in software; it is still up to the capabilities of the QA engineer to log it accurately and the developer to correctly fix. Every one of us are well aware that all software that is tested and released is not bug-free. Often times management decides to ship a product if the existing bugs do not affect users significantly, or if a business need outweighs the time required to fix an issue. It is always considered to be more cost effective to focus on fixing critical bugs and sometimes let lower priority issues go untouched. For instance, in case of software that is critical to human health and safety – such as in the medical, construction and defense fields – there is zero tolerance for defects, so software quality assurance and fixing of all defects takes on a higher priority.

 

Myth – Testing in Agile is best left to the developers.

Fact –  With Agile and devops blurring the boundaries of the roles of testers and developers, why not let the developers test and save the product owner a ton of money? Why have testers at all? Because testers not only test for functional issues; they bring to the team their knowledge of good quality process, their understanding of business goals, and a broad perspective of the application that developers often miss. They are an important link between the product owners and the technical team, and are an important piece within the overall development team and process.

 

Recommended Posts

Leave a Comment