S3 tech blog

When most people think of Quality Assurance—or QA to the initiated—they think of a room full of obnoxious overgrown teenagers pounding on their keyboards trying to make software malfunction. Anyone with IT experience in web application development knows there’s more to it than that, but many custom software projects run into problems because the relationship between the development team and the QA team is allowed to become too antagonistic. The developers work to make the users’ lives easier, then the QA people try to find flaws in their work. While many software vendors take a reductive approach to QA, treating it as nothing more than a search for bugs, the best approach to custom projects is to integrate QA processes into the development process from the beginning. In other words, as soon as you’re done answering the question “How should it work?” you should be going on to answer “How will we know it’s working that way?”

Quality Assurance vs. Software Testing

There’s more to quality that an absence of bugs. The first and most important criterion that must be met for a development project to be considered successful is that the application does what it’s supposed to do. So anyone tasked with ensuring the software meets basic quality standards needs to understand the client’s vision for how it will function in a real work setting.

That means the Quality Assurance process begins at the same time the development process begins. Instead of developers working in isolation to build applications they hope will get past a QA team which is also working in isolation, the development process should ensure open and frequent communication between the two groups. QA and development, in other words, shouldn’t be thought of two entirely separate processes—they are two aspects of the same process.

Many people think of the terms QA and Testing as interchangeable, though, and many custom software vendors in Viet Nam Software Services treat it that way. But there’s a big difference between a software tester, whose job is to identify errors and bugs, and a Quality Assurance Engineer, whose job is to create, implement, monitor, and revise the processes that ensure the software meets the functional requirements that the client has agreed to. Testing is just one subset of the broader category of Quality Assurance processes.

One-way Communication

The way the old, antagonistic approach to QA often looks in practice is that everyone on the development team has a set of tasks assigned to them, they complete the tasks, and then they’re finished. The only clues each of them has to the overall vision of the project comes from artifacts in the TFS. So the developers are writing code based on assignments from on high, and later on testers come at the code from multiple angles trying to identify errors.

With two-way communication channels, though, like those used in various agile methodologies like scrum, the individual developers are made aware of the overall goals of the project. And that means they can let the higher-ups know when things on the ground start deviating from the client’s vision.

When it comes to Quality Assurance, it’s the difference between trying to discover random bugs on the one hand and testing with a purpose on the other. But QA’s role actually begins even before the developers get to work coding. Their first task is to ensure the artifacts in the TFS align with the true requirements of the projects. In other words, the QA engineer needs to make sure at the outset that the mobile application development will correspond with the client’s user stories about how it will function in a real work scenario.

The philosophy for QA that comes out of agile approaches is that testing should be as close to developing as possible. The closer the requirements developers are working to meet are to the user stories created by the client, the more likely the project is to be considered a success by that client. QA is part of that same process, and it makes sure that what the developers are creating does everything the client wants it to do—and, of course, that it does so without any bugs.

Source