Software QA vs Test - What's in a Name?

JULY 20, 2016 // By Bill Roske

Quality Assurance, Quality Control, Testing. In software circles sometimes these terms are used interchangeably. Other times, people want to make a clear delineation between QA and QC.

Back in the 80s I worked at a company that built computers. I was in the software division, but make no mistake about it we were a manufacturing company. I was in the Testing (or IV&V: Independent Verification and Validation) team, NOT Quality Assurance (to this day, I shudder when someone says they are in the QA department). Why the distinction? Because we had a nick-name for the Quality Assurance team: "The Process Police." Their role was to make sure we had the process we planned to use documented, and that we followed the process… as documented. They carried clipboards and reminder cards with the process diagrammed out and signed off on deliverables (yes, literally signed their name on a QA stamp on the printout). Not that they knew if the deliverables were any good or not, just that we had followed our procedures to deliver them. The theory was (is?), if you document your process and make sure everyone follows it, then you will get consistent quality. Not necessarily GOOD quality, just consistent. In manufacturing, consistency is key. The ISO9000/1 standards are built on that philosophy.

Quality Control, on the other hand, was all about measuring the defects and adjusting the (documented) process to eliminate defects. In that way you could improve the (consistent) quality. One could argue that this is the role of Software Testing. But, to me, that is a problem. Relegating testing to the role of exercising the end product only tells you how bad it is. It does nothing to inform the organization that you are on the right, or wrong, track. That's kind of like getting on a plane and finding out where it's going when you land. Too late to choose a different flight plan.

So, what should we "aspire” to? Don’t get me wrong. There is value in learning from the past and having a defined process for software quality and then following it (QA) and improving that process, and product quality, along the way.

In this day, when time to market seems to get more important with every "sprint," measuring isn't enough. Testing isn't enough. If you are responsible for quality (of software), you don’t just want to measure and adjust so you get it right next time. There may not BE a next time. You want to ENSURE the software is of high quality with release ONE.

But, what should that process be? What tools and techniques will we use to not just measure, but ensure the quality of the (software) product we want to deliver? QA is about making sure we follow our process. QC (testing) is about exercising the code and measuring the distance from desired to achieved capability. What do we call the (arguably more important) task of ensuring that the desired product is going to hit the mark?

I like the term Quality Engineering (QE). QE is about helping to engineer quality into the product. Providing feedback at every step in the process of building software. It means verifying and validating the requirements BEFORE we design. That is, designing test cases BEFORE the product design. It means validating the design against the requirements. It means validating the finished functionality against the requirements (executing those tests we designed). Some people call it "Shifting Left." Why? Because we want to move the focus on quality up-stream in time. If time flows from left-to-right, as all Gantt charts tell us it does, then we want to shift left. But once you shift left, you are clearing away potential defects that would come from ambiguous requirements. You clarify how the product is supposed to behave (with test designs) before you design or build the product. That way you are preventing bugs by providing information to validate the design with the (less ambiguous) requirements. Really, ALL downstream "work-products" are validated back to requirements. Testing (exercising the code) is a "tester's" job, but it is just one tool in a Quality Engineer's toolbox.

We, as a "Software Quality Community," need to aspire to be Quality Engineers, with a whole box of tools. Not "just testers."

If you’d like to contact Magenic, email us or call us directly at 877-277-1044.

Categories // Quality Assurance & Testing
Tags // Quality Assurance, Quality Control, Testing, Quality Engineering

Get Started

Contact Us