7 Most Common Myths About Quality Assurance

Piotr Szczęch - Quality Assurance Manager
7 minutes read

As a Quality Assurance professional for 11 years, I’ve come across many misconceptions and myths out there about what QA specialists really do. These myths can prevent us from fully understanding the importance of QA when it comes to designing and building great software.


Misconceptions come from things we do not truly understand. Some believe quality assurance is simple, or that it can be done by anyone, or worse—they believe QA can’t lead to substantial time and cost savings, as well as greater revenue and benefits to a company.


Let’s debunk the most common myths surrounding QA in software development. I’d like to share my experience from a QA manager’s perspective, and communicate the true value of quality assurance.


1. Quality Assurance is Always Expensive

This may be the most popular myth, and for many reasons, it’s my personal favorite. The idea behind this myth is that QA will delay a business process, or involve unnecessary roles and tools, and thus, make projects more expensive.

The truth is that building solutions will always be an investment. We accept the costs of developing a solution, knowing that down the line, it will return a profit. To achieve results, we need to ask ourselves if introducing (or improving) the product will be of high quality, reach our goals, and achieve the intended business result. If the intended business result is to reduce operational costs, then QA is critical to ensuring it.

The myth that QA is an ‘additional cost’ is far from reality. A proper quality assurance process actually reduces overall costs, by mitigating business risk, and preventing us from delivering a solution that could cause harm to the company or its clients. QA also ensures that new updates and changes ensure the business stays competitive. All these factors considered, having a professional QA team delivers more value in the long run.

2. Quality Assurance and Testing Are The Same

This list would not be complete without this myth which is one of the most common mistakes in thinking Testing and Quality Assurance are synonymous.

While a great Quality Assurance process does require testing, these are two very different concepts, and often require people handling very different roles. Consider the following definitions:

Quality Assurance involves all activities planned to be taken across the whole development life cycle in order to keep the quality of the solution on a sufficient level. It may and should involve different types of testing, but those not close to them. Great QA should take into account all of the aspects which can have a positive or negative impact on the solution and adjust the process accordingly to reduce risk to an acceptable level.

Testing is a specific operation commonly used to verify the functionality of a feature or product, and can be handled with automation or manually by testers. Testers are responsible for evaluating new and existing code, to identify and help remove bugs, glitches, and other user experience issues. Testing is a part of Quality Control, but not necessarily looking at the big picture of risk mitigation.

This myth is dispelled when businesses understand that Quality Assurance is not just Testing. It is an integral part of software development, brand reputation, business efficiency, cost-efficiency, and customer satisfaction.

3. Quality Assurance is Responsible For Everything

When a feature or product releases, QA is often the last line of judgment between the company and the customer. This has influenced the myth that QA specialists are the “final call” on a project, all the responsibilities can be put on their shoulders.

The truth is that QA is a complex topic, and a good QA strategy puts responsibility in the hands of each team member working on the solution. While the SQA team formally owns the ‘QA process’ and is accountable and responsible for the implementation, it is hard to imagine a successful process without the engagement and cooperation of the whole team. The team includes business executives or decision makers who need to understand QA and how it relates to the rest of the business. Everyone involved is dedicated to ensuring quality for their respective roles.

4. Quality Assurance is All About Software

This myth usually comes from a lack of understanding about software development. QA specialists, as described above, have many roles that do not involve testing or validating software.

QA specialists must often look outside the system, as its quality is a representation of all things happening across the development life cycle. Every decision from framework selection, choosing technologies, and building the team, will affect the risks and therefore the quality. We also have to ask ourselves if the customer will be happy, or find it frustrating, or difficult to use. A good QA specialist needs to know how customers react to a product or changes to their product.

5. There is One Great Quality Assurance Approach

This myth assumes that there’s a singular QA approach which will be effective for all our projects, regardless of their industry, technology, or framework.

If this were true, I might not have a job! Luckily for me, it is impossible to define a single approach that would fit multiple products or businesses. Each product and company is unique. Every digital product has its own set of requirements, and each one has a different perception of quality. The QA strategy is closely tailored to a product’s needs, context, surroundings, and expectations.

Of course, there are some reusable parts of quality assurance, like common standards, procedures, toolsets, and techniques that can be used as the building blocks for our software development process.

6. Some Tests Are More important Than Others

This myth favors certain types, or levels of testing, before others. Some may say that, “We only need an automated test” or, “We can only rely on unit and integration tests.” Some might even claim the “We don’t need a User Acceptance Test.”

The misconception here fails to take into account that each quality assurance test has its purpose. The decision about using it or not should be taken only based on the benefits which they bring. While designing a test approach in your QA process, you need to understand how different levels of testing complement each other, and the same goes for the different test types.

7. Quality Assurance Prevents All Errors

This myth is the hardest to deal with, as we and our customers expect that by involving QA specialists, we have delivered a perfect product without any issues.

Unfortunately, the truth is, that even if introducing the best QA process with the best specialists and tools with 100% coverage of the system and its requirements, it still does not mean that there are no bugs left.

Aside from that such QA setup would be effective in the chance that after moving to production new issues will be found still exists. The whole QA process aim is to reduce the risk of errors not to prevent all of them. Test as a part of that process in very nature does not have an ending. We define it in our approach to keep the time and costs of the test process in a rational range. I like to compare that process to a book, development is more like writing the book and we can see the clear end of the story. Testing on the other hand is like reading, if you finish the reading there is nothing that prevents you from starting all over again, and still you can find new things.

Conclusions/Summary

Ultimately, Quality Assurance is about leading towards a better product, but using multiple perspectives (developers, business decision-makers, and end customers) to get there.

These myths aren’t the only ones out there. The key to dispelling myths around QA is all about communication. Once people understand the full value of quality assurance, it’s easy to relate their crucial role in the process of building great products.

On-demand webinar: Moving Forward From Legacy Systems

We’ll walk you through how to think about an upgrade, refactor, or migration project to your codebase. By the end of this webinar, you’ll have a step-by-step plan to move away from the legacy system.

moving forward from legacy systems - webinar

Latest blog posts

See more

Ready to talk about your project?

1.

Tell us more

Fill out a quick form describing your needs. You can always add details later on and we’ll reply within a day!

2.

Strategic Planning

We go through recommended tools, technologies and frameworks that best fit the challenges you face.

3.

Workshop Kickoff

Once we arrange the formalities, you can meet your Polcode team members and we’ll begin developing your next project.