What does a QA team do? Now, they’re ‘doing QA’—or so they say. But what does that mean? And is it true even?
The answer is twofold. On the hand it, it is trivially true that we as QA engineers or similar roles ‘do QA’, as that is an integral part of their job description. On the other hand, it is equally and undoubtedly false. This essay is about why that is.
The International Software Testing Qualifications Board (ISTQB) defines “quality assurance” as ‘activities focused on providing confidence that quality requirements will be fulfilled’. This can be contrasted with “quality control” (QC), which is defined as ‘activities designed to evaluate the quality of a component or system’. We set aside related terms such “quality management”, “quality engineering” and the like. They are worth to be discussed separately some other time. (By the way, the ISTQB definitions are based on ISO definitions, of course.)
Now, when people talk about ‘doing QA’ (in software engineering) they usually mean that they hand over some piece of work, typically some code implementation, to specialist who check whether this artefact conforms to some reference. This point of reference might be a user story, an acceptance criterion, a requirement, or even an idea in the head of some stakeholder (e.g., a product owner). But this activity is called testing, right? The textbook definition reads: ‘The process within the software development lifecycle that evaluates the quality of a component or system and related work products.’
Before I return to quality assurance, let me briefly point out that software testing includes far more than what is commonly understood by the term. Without going too much into the details, let me just briefly mention three common misconceptions.
First misconception: Testing involves the execution of the system under test. No, it doesn’t. Dynamic and static testing complement each other. And the latter is as important to a coherent test approach as the former. Second misconception: testing concerns the functionality of the system. While it is true that this is a major aspect of most testing activities, all work towards ‘evaluating the quality of a component or system’ constitutes testing. In other words, what is important is that there is some artefact and a corresponding point of reference. Oftentimes, this point of reference will involve non-functional determinations. Third misconception: testers test code. While it is true that they do this, their mission encompasses the ‘evaluation of the quality of a component or system and related work products.’ That is to say, a test object might be any artefact whatsoever in the context of a software development lifecycle that contributes to the overall quality of the product. This includes requirements, user stories, wireframes, software architecture, system specification, interface definitions, and so forth.
Back to quality assurance. It is at least partially due to the dominance of the American software industry and its corresponding job market that QA is oftentimes identified with QC, which, again, is identified with testing. However, this is conceptionally wrongheaded.
Both activities have in common that they deal with product quality. But the direction of impact is entirely distinct. Quality control is a rather simple activity. (No, it isn’t, but let’s pretend for a moment.) You have two entities, A and B. A is a piece of work (code or otherwise). B is a point of reference (e.g., a requirement). What a tester does is a simple comparison: Does A conform to B? In this sense, testing is ‘just’ a series of comparisons.
Quality assurance is different. The activities subsumed under this umbrella term do not involve comparisons. Also, they are not directly concerned with the test object per se (i.e., the system under test). Remember that quality assurance comprises ‘activities focused on providing confidence that quality requirements will be fulfilled’. Testing could be one such activity, but it is certainly not the only one. Maybe it’s not even the most important one.
While quality control checks the quality of an artefact, quality assurance fosters an environment that leads to overall higher artefact quality. So, the work object of QA is a set of processes rather than a set of artefacts. Moreover, QC reacts—its objects of study are taken as given when pulled for comparison—while QA acts. In order to ‘provide confidence’ the processes required for this need to be designed, implemented, and maintained in the first place. In terms of a software development lifecycle, QA happens at earlier stages, whereas QC happens later in the lifecycle.
So, is it now true that QA teams ‘do QA’? On the face of it, they are primarily occupied with QC activities. In that sense, these teams do not do QA at all. Yet, software engineering organisations are ultimately interested in high product quality. On that path, QA and QC are complementary activities. One is as important as the other. This is why any successful QA team strives for incorporating as much actual QA activities into our work as possible. So, the answer is: Yes, QA teams ‘do QA’—but this involves far more than you might think.
No responses yet