As a software quality assurance (SQA) professional, I’m often confounded by the confusion that still permeates many parts of our industry when it comes to understanding exactly where Software Quality Assurance fits in the day-to-day of a software-focused organisation.
Software QA is not just about Testing. It is one of the most important processes stretching right across the entire software development lifecycle (SDLC). The following is a quality assurance Q&A that sets out what software QA is all about, how it works, what it’s not, and common mistakes that can easily be avoided when considering software QA for your business.
What is QA in a software development space?
It’s a process that focuses on a set of requirements that need to be in place to enable us to develop and deliver reliable products and solutions. A well enabled QA process establishes a company’s credibility and boosts customer confidence in its products and solutions. The driving force behind QA in software development is ISO standards. These speak to why we have quality, what it’s for and what we’re measuring. That is why we are also an ISO27001 registered company.
How does QA differ from software testing?
Physical Testing and QA can be seen as two interchangeable processes. One aims to ship software that matches actual requirements, and the other ensures you increase the standard of your quality so output to customers is competitive.
Software Testing concentrates on identifying actual defects and errors in software. Testers apply rigorous processes to check software deviations from requirements while optimising the maturity state of a company’s software. Software Testing is part of an overall quality process, not the sole process. It also focuses exclusively on product-oriented activities, while software QA focuses on various other items and processes and not just product-oriented activities.
Quality Assurance sits across both the development and implementation phases of software development to ensure that teams follow key procedures of the SDLC. It’s a proactive activity that focuses on the software and development processes with continuous improvement, as well as risk of defect and prevention failure.
How does Quality Assurance differ from quality control?
These two often get mixed with each other but in practice are very different. Quality Assurance is the responsibility of everyone involved in the software development process, while quality control is the domain of a specific team. QA is all about preventative activities, while quality control focuses on corrective processes. Quality control is usually a subset of Quality Assurance, and software testing is a subset of quality control.
Why is maintaining Quality Assurance so important?
Quality Assurance is a critical part of SDLC and soft development. If software development doesn’t meet international standards, it could pose severe issues for organisations. In the digital age, quality becomes important against standards and outcomes, and also determines how fast products get to market and how they compare to their competitors.
How do Quality Assurance teams determine software quality?
There are two main approaches QA teams use to determine software quality: quality attributes, and defect management. The quality attributes approach drills down into respective areas, values specific to your organisation or to quality of evaluation. This typically covers six major subject lines: portability, maintainability, efficiency, usability, reliability and functionality.
Defect management identifies issues in the actual software. As Quality Assurance professionals we see where breakpoints are, and can advise our clients how to resolve them and mitigate future issues. Quality Assurance teams might identify issues not picked up by developers, and then feedback support to the development team on how to better identify those issues. It’s important that controls, capabilities and processes in other areas are all functioning properly so that overall quality is not affected downstream and the risk is reduced.
What are some of the common mistakes made in Quality Assurance?
Lack of root cause analysis. Root cause analysis identifies current defects and traces them back to the cause to eliminate future instances. Oftentimes development projects are under tight deadlines and sufficient time isn’t made for identifying and understanding the cause of issues when they occur. QA will find issues that will then be rushed over and quickly fixed, but the impact is not always traced back to the true cause, which increases chances of recurrence.
Failure to ask questions. As QA experts we should not be afraid to engage with developers and testers and interrogate them about their processes, or with project managers and query restrictive deadlines. We should not be afraid to push back or say no when something threatens quality.
Automation. Many think automation is plug and play, but this is dependent on your code. If code is not geared to automation, it can be tricky for the QA team to run automation, which impacts refactoring of test cases, continuous changes and requirements alignment, which speaks to a bigger understanding of quality. Automation becomes more efficient when defect management is managed, and code practices and ISO standards are met.
Forgetting about the user experience. A common thing we forget in the day-to-day when we get stuck into the detail of QA is how this impacts the user. We need to focus on the user experience, especially in the digital age. With robotics, automation and AI proliferating, the user experience is becoming more and more important, not only to improve user success with your product but to enable your success as company, your brand, and build confidence in your teams.
Passing the buck. Also known as blaming others for bugs. QA teams are finding bugs and that sometimes falls on development teams. It could mean development teams aren’t following best practice, but doesn’t necessarily mean developers are not providing the quality required, only that they might need to take a different approach on how they develop. If we’re not careful, this can impact motivation, teams and company culture. We need to step away from blaming others. The goal of QA is to improve the software, not to highlight inefficiencies or point fingers at people or teams. It’s a collective effort and shared responsibility.
We can’t fix software that’s already been launched. This is a dangerous and false perception. The key is how quickly we can fix issues and what’s the most effective and efficient way to do so. A thorough understanding of your processes and controls is essential to getting to issues quickly and fixing them before they become insurmountable.
In closing
Make sure you read and gain domain knowledge on QA. Your SDLC is one of the key aspects that will speak to your QA, and vice versa. If your SDLC methodologies and activities are not aligned to QA, it will have a downstream impact. The primary goal of QA is in your SDLC, and delivers a product that not only matches your requirements but also clients’ requirements, is functional to your market and puts you ahead of the rest.
Delivering a flawless software product is simply not possible if you don’t have an experienced software QA team that helps relay the understanding of QA in your organisation and is supported by your business strategy, culture and way of work.
About Candice
Candice Coetzee is the Head of Strategic and Specialised Testing for Inspired Testing, a global testing and quality assurance company and Thomson Reuters Legal partner.
