Yes. That’s exactly what I’m saying.
In the software testing world and in the quality assurance industry, this is a sticky point. It irks us that these terms are oft used interchangeably. How many times do you hear someone say, “Has that gone through QA yet?” when the person is talking about testing? It’s actually an incorrect statement. Personally, I have worked at numerous Fortune 100 companies where my title included “Quality Assurance” or “QA” when my role had absolutely nothing to do with QA. At all.
Are you confused?
Well, that’s what I want to do—help explain the difference between Quality Assurance (QA) and software testing.
So, first let’s talk about testing.
Testing consists of many activities, but most people use it to describe the activity of executing tests, also known as test cases. A test case has explicit steps that have predefined (key!!!) expected results as well as known inputs and outputs. When these activities and steps are followed—or “executed”— the results of the activities (‘actual results’) are compared to the expected results. The test passes if the actual results match the expected results. The test fails if the actual results differ from the expected results.
So, the distinctive thing about the above is that there are expected results identified and documented before the tests are executed. That means one thing. The tests are planned and someone must figure out how the application under test should respond when the tests are run. So, there has to be enough information in the requirements and design documentation in order to figure this out. If you can’t figure out the expected results beforehand, then you have nothing to compare your actual test results to after you execute the tests. This makes it extremely difficult to measure if your tests pass or fail.
You might be thinking this: You don’t have actual test cases documented but your application is supposed to add 1 + 1 and you know that this equals 2, so why do you need a written test for this? You know that if you get a result other than 2, the system fails.
Yes, that was in fact a test—an undocumented test case. You compared the results to a known, expected answer, albeit in your head, and then determined if the actual result matched your expected result.
The important thing to note about the example above is that the test case only resides in your head. No one else’s. What if you need someone else to execute this test? How do you know that person knows that the expected result is 2? How do you know that person has the same expected result as you? (This is starting to sound like a Dr. Seuss book with the rhyming sentences.)
The 1+1 problem is an easy example, but software testing is not typically that simple. If it were, we would not need requirements, design, architects, developers, or testers.
So, written tests are needed because the person(s) executing the tests may not be as familiar with every nuance of the system.
That’s testing in a nutshell. A VERY high-level explanation, at least.
So what is quality assurance or QA, you ask?
According to IEEE, QA is a planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to technical requirements.
Per SEI’s CMMI, Process and Product Quality Assurance (PPQA) is responsible for providing staff and management with objective insight into the processes and associated work products.
The role of Quality Assurance is to audit compliance, improve processes, gather metrics, and communicate findings. The QA role helps to implement quality throughout an organization by evaluating and improving processes and templates, typically using industry-recognized bodies of knowledge as baseline standards. These standards can be from IEEE, SEI’s CMMI, ISO 9001, COBIT, or ITIL. All of these standards offer different levels of guidance—some are higher level frameworks while others offer detailed templates for use.
Is there a policy, processes, and communicated templates in place for Requirements Management? Are the team members adhering to the policy? To the Configuration Management process? To the Change Management process? How are these processes being monitored and/or audited for compliance? Can these processes be improved and become more mature?
Quality Assurance is really about evaluating, monitoring, assessing, and improving an organization’s IT processes in order to help build quality checkpoints into the development process. It’s not testing.
So why the misnomer? Why do so many people misuse these terms? That’s a good question. Your task is to spread the word to the masses. Get the HR Department to rename job roles so that testing positions have the word ‘test’ and not ‘QA’. Go forth and conquer, I say!
Question for you: Does your organization properly use the terms “quality assurance,” “QA,” and “testing?” Does your job title correspond to your function?
Let us know. We want to hear from you!