Software Quality Assurance vs. Quality Control: What’s the Difference? process.st/software-quality-assurance-vs-quality-control/
11/21/2016
Thinking the terms ‘quality control’ and ‘quality assurance’ can be used interchangeably is a common mistake. Whoever coined those terms did nothing to clarify their differences, but in fact: Quality control (QC) makes sure that your product isn’t riddled with bugs. Quality assurance (QA) makes sure engineers are following processes to reduce future bugs, and write code more efficiently. Quality control is something development teams do every day. They squash bugs in the code they wrote, and run tests to catch future errors. Quality assurance is the overall management of development processes that make sure less testing and QC needs to be done. At Process Street, we’ve already looked at the wider implications of QC and how to run tests on your software. We’ve even provided you with a bunch of pre-made software development processes you can adjust to your own team. In this article, I’ll go into an explanation of quality assurance in software teams, and how you can use this information for your own developers.
Common features of quality control No matter who you are and what you do, quality control will be part of your job. You will always check your work to
1/4
make sure it doesn’t go out with errors.
A key part in understanding the role of QC in your organization is to realize that checking work is as far as QC goes. We’ve found that the best way to reduce errors is by using a checklist, and working through the steps until everything’s been approved. We have checklists for the low-level QC side of software development, including testing, and deploying. But we also have SOPs for creating and re-writing processes — two things of massive importance in any properly organized business. Get these two checklists here: Creating a process Optimizing a process
Does every project need quality assurance? While every project definitely needs quality control, not everything needs quality assurance. With QA, it’s a matter of optimizing the process, not the output. So, for one-person development teams that can put out clean code and QC it on their own, QA isn’t something you need to waste time on. The most common issues arise when multiple developers work on the same architecture. However, as Rick Hower puts it:
“Which projects may not need independent test staff? The answer depends on the size and context of the project, the risks, the development methodology, the skill and experience of the developers, and other factors. For instance, if the project is a short-term, small, low risk project, with highly experienced programmers utilizing thorough unit testing or test-first development, then test engineers may not be required for the project to succeed.”
What are the most vital process problems to fix with QA? Those who work closely with developers will know that you can’t always get an answer about when a project or task
2/4
will be done. You’ll get answers like “I can get that out in a few hours, no problem”. That kind of answer is almost always wrong, and is the main reason for QA.
Software gets bugs because humans make errors, overestimate the time involved, rush to meet deadlines and are trying to juggle multiple things at once. For that reason, QA is put in place to improve: User stories. Without solid user stories, the requirements the software fulfills are blurry. This means that developers can’t run over deadlines pointlessly expanding features. Development timelines. QA processes aren’t just about checking code for bugs, they’re about the entire project management aspect of developing software. Testing practices. This means developers should be required to test and show their work as they go along to make sure the software is perfect. Scope creep. It’s not enough to make user stories. Efficient teams stick to them, and know when they’ve finished the job. Scope creep is when a project becomes bigger because developers chip in with additions. Communication. Spanning from informal Slack chats to official documentation, QA processes should be in place to encourage and require communication that centralizes information and gets all developers working together.
How to introduce new quality assurance processes into your organization There’s no one true way that all teams should operate, but it is essential to implement processes. And, depending on the size of your organization, that could be an easy task or a difficult one. Enterprises will have established methods for getting new processes approved and implemented, such as testing in small teams and expanding. For small businesses, however, it’s as easy as introducing your team to the set of processes (for example, a process for testing, a tracking system for issues, and SOPs for improving old processes). Keep this in mind: Implementing QA processes shouldn’t come with a cut to productivity, so it needs to be done gently. The kinds of processes you should start implementing are, according to SoftwareQATest.com:
3/4
Requirement/user story management processes, with a goal of clear, complete, testable specifications embodied in requirements, appropriately-sized user stories, or design documentation Design reviews and code reviews Post-mortems/retrospectives
Use Process Street for quality control and quality assurance Process Street specializes in quality control and assurance. You can’t go wrong with a checklist, and if you do there will be logs stored in the app that shows where the process broke down.
Load up your own processes or use some we’ve prepared for you, and start running checklists for each project and working through the steps. Check out the full list of software development processes here and start writing software that works perfectly.
4/4