QA: What It Is & Why You Need It
Quality — it’s one of those words that means everything and nothing.
Even with something physical, quality is usually something you feel more than you verbalize. It’s the heft of a nice watch or the softness of a piece of leather.
When you pay for quality, you’re paying for trust. You can trust that the watch is authentic, that the leather will hold up.
Quality isn’t an accident. That feeling of substance and right-ness comes from a tangible list of checkpoints throughout the product’s creation, ensuring things are being done in ways that culminate in a high-quality outcome. This is known as quality assurance (QA).
In software, “quality” may be slightly more abstract than with a physical object, but the spirit is the same.
The heart of QA serves to understand and meet the customers’ needs and expectations. QA specialists work alongside developers to keep their code on track to the outcome necessitated by the user. By the time the software comes off the “assembly line,” all the parts add up to the original vision — if not more.
Hard skills meet soft skills
Many organizations these days are exploring ways to eliminate the use of dedicated QA specialists. Some feel that developers are capable of testing for quality themselves. Others think that the need for QA disappears when developers become dedicated enough to code at the highest possible quality in the first place.
In the case of the former, this may be true. But developers are busy. Their work requires intense focus, and taking up their bandwidth for QA doesn’t make the highest use of their skills. And like anyone, developers can be biased when it comes to evaluating their own work.
In the case of the latter, this might be true if quality existed on a black-and-white spectrum. But code lives in a world of color. Sure, there’s universally bad code, but what’s right can depend on the project.
That’s where QA steps in, as the connective tissue between the designer’s vision and the code that makes it real.
Communication
QA engineers have the communication skills to distill the project’s requirements into concrete coding objectives. The idea being that if the developer’s code achieves those objectives, it enables the necessary function from the user’s end. More on that in another blog post :)
QA also reports defects that surface in testing and help pinpoint their root causes. This takes a fair amount of translating, but when done right, can save developers tons of time.
Testing
QA plans, creates, and executes tests of the software at various increments through the development lifecycle. These tests are based on the product’s requirements and cover various scenarios, inputs, and outputs.
The point of these tests is two-fold: find defects in the software and ensure the code does what the user needs it to do.
Process improvement
Again, “quality” can be defined differently from organization to organization, from project to project. QA helps cement the organization’s sense of quality and implements policies that bake in quality at the deepest level of the software development process.
Ultimately, QA’s goal is to proactively prevent lapses in quality. They help developers get it right the first time and save everyone the headache of backtracking and reworking.
Collaboration
“Connective tissue” really is an apt description of QA in action. They navigate interactions with clients, designers, developers, project managers, and other stakeholders, and they share the appropriate knowledge from one to the next. That takes a lot of tact and a lot of work.
When project requirements, design, or scope take a pivot, QA helps bring everyone together to solve problems as a team and keep everyone on the same page.
QA Red Flags
The QA process is vital to the success of your app project. It’s just as important as coding competency. As you search for an app development partner, there are a few red flags to be wary of.
There is no QA
Automated testing is definitely a thing, but it can only go so far. There are always edge cases and details that merit human discernment. If developers are performing their own QA, the risks are obvious. It’s kind of like someone taking a test and grading it.
QA happens at the end of the development lifecycle
In the QA/development ether, you may run across the phrase “shift left.” This refers to the practice of bringing QA in at the earliest stages of the process to give developers the best possible idea of the outcome they should be aiming for.
When QA happens at the end of the development lifecycle, it’s much more difficult to isolate the root causes of a defect, because at that stage, the app has been fully assembled.
QA and development have a contentious relationship.
Yes, part of QA’s job is to try and poke holes in the developer’s work, but they are working toward the same goal. Testing the validity and integrity of the code is simply a necessary evil. In a healthy relationship, developers love QA, because QA finds defects at an early enough stage that they are easy to remediate.
A contentious relationship shows a lack of trust. It may indicate that QA is (or is treated as) a box-checking measure that frustrates the team and delays timelines.
In QA We Trust
Remember, quality comes down to trust. Users must be able to trust the product. To get there, the integrity and function of the product must be validated at key points in the software development lifecycle. QA makes that happen, and without them, it’s almost guaranteed that your project will go off the rails during development or come up short when it hits the market.
