A Beginner’s Guide to QA for Custom Software Development
These days, even non-technical people seem to have an understanding of, or at least a familiarity with, the Quality Assurance (QA) process. What they may lack is clarity around exactly how it’s applied in the custom software development process.
Quality Assurance, the term itself, comes with a long history—that predates custom software development and even computers themselves. Quality Assurance comes from the manufacturing world where workers perform quality checks to ensure that a product meets its specifications. We’ve all seen, for example, the small stickers that peel off the insides of pockets in new shirts or pants. Those stickers tell us that the product was inspected, passed, and even tell us who performed the check.
How does QA work in custom software?
In manufacturing, people will say you need to watch what’s coming off the line to make sure that you know the machines have produced the right product and that it meets its specifications.
It’s not as easy in the custom software development world. Custom software, by definition, does not always follow a prescribed list of standards. Instead, in custom software, you are testing your finished product against the requirements to see if the implementation has followed the design. Quality Assurance for custom software is similar to custom home building where you look to see if the finished home matches the blueprint. For this reason, the software requirements are the foundation of any quality assurance process as they are the instructions that were provided to guide the development of the custom software product.
To err is human
Humans write code. If there’s one thing that’s consistent about humans, it’s that we make errors. Those errors get embedded into the software. In custom software development, that’s where Quality Assurance comes in and plays its critical role.
In the Quality Assurance process, QA analysts test software in development to try to catch where humans might have made errors. Sometimes, these errors are the kinds you might have expected.
For example, suppose you have a custom software application that calculates customer satisfaction scores for a customer care department within a large company.
Writing the code for that calculation isn’t just the straightforward writing of instructions. While it might seem easy to do something that looks right, the code may ultimately miscalculate customer satisfaction scores because the coder missed the parenthesis around a calculation.
Small errors in coding a calculation can totally change its output and these errors become embedded in the software. Quality Assurance is certainly designed to catch and remove these kinds of errors before they get deployed to production.
QA’s Hidden Value
What a lot of people may not know about Quality Assurance is that it doesn’t just involve looking for errors in the software. QA also looks to make sure that what we developed fulfills the requirements for the software project.
It’s pretty easy to discover that we have an error if you input 2+2 and you get 5. But what if that calculation never should have had addition in the first place? What if the formula to calculate the customer satisfaction score should have used multiplication instead? A good QA process will check that code not only works, but that it fulfills the requirements and objectives.
Quality Assurance isn’t just checking for programmatic challenges, it’s also looking to validate that the requirements themselves have been met. To do that in Quality Assurance, you set up a series of test scenarios to help validate that the code is doing what the business user intended when the requirements were created. We use the requirements as a source of testing conditions.
Quality Assurance Analysts look to make sure that the code for custom software achieves all three of its objectives:
• It operates correctly
• It fulfills the business and functional requirements
• It meets the performance requirements
But there’s another difference between QA in manufacturing and QA in custom software development.
QA does not just happen at the end
Following the manufacturing analogy, it’s easy to assume that QA testing happens at the end, after the product is developed. In software development, Quality Assurance should happen in parallel with development where testing can be performed continuously. This is similar to a componentized manufacturing process where each component of the product is tested individually before use and then the finish product is tested again at the end to make sure the final construction went as planned.
In custom software, QA analysts are not just looking at a finished custom software product. They watch the custom software product come together throughout the process. Because custom software can be really large and have a lot of code, we want to catch problems early so we aren’t looking for a needle in the haystack at the end.
In custom software, Quality Assurance is a consistent process. Ideally, QA should always be built into the development process. QA analysts should be iteratively testing as the project goes along. Testing only at the end will not be adequate.
There are certain methods of applying QA that are better than others. From our experience, we subscribe to the belief that Quality Assurance should be done in parallel and in conjunction with development as part of the development team, not as an end function that occurs after development is complete.
Would like to learn more about our approach to Quality Assurance and custom software development? Download our eBook below.