When it comes to software development, nothing is left up to guesswork. Every aspect of an application is, or at least should be, very deliberate. Once business stakeholders, programmers and designers have agreed upon a clear vision and established the skeleton of a roadmap, they enter the execution phase. At this point, QA management may also be very involved, depending on if the organization uses a waterfall model or agile development. The job of these testers is to make sure that goals have been met in terms of critical functionality, user experience, the integrity of the build and user acceptance. The idea is to preempt every possible shortcoming of the application before it's released. There should be no surprises.

Somewhere in this application life cycle, teams may perform something called a code review. The interesting thing about a code review is that it doesn't necessarily have a hard-and-fast definition. Depending on the team, it may include only certain departments, or it may be all-inclusive.

In brevity, the answer to the question "Is code review considered a part of QA?" is, it depends.

A Closer Look At The Terminology

TechTarget contributor Margaret Rouse defines code review as "a phase in the software development process in which the authors of code, peer reviewers, and perhaps quality assurance (QA) testers get together to review code."

Three things immediately stick out in this definition. First, referring to it as a "phase" implies that it happens at some point in development, but it doesn't specify at what point. Later in her assessment of code reviews, Rouse touches on the idea that there isn't really a set time in development when it should occur. It could be after the main build is complete, or it could be after a patch has been made.

Second, the phrase "and perhaps quality assurance (QA) testers" signifies that QA may or may not be a part of code reviews. In online forums about software development and code reviews, this sentiment appears to be echoed. In one thread on StackExchange, developers, designers and testers shared personal experiences with code reviews, and they all seem to differ. Some claim that software testing is never a part of code reviews, and that it's more for developers, whiles others say that QA is a part, and that tests also need to be code reviewed.

This segues into the third element of Rouse's definition, which is the phrase "review code." Rouse explains later in her piece that the review may refer to sifting out potential flaws, looking for security vulnerabilities, assessing developer comments and auditing for compliance with coding standards. In theory, all of this is technically a type of QA. By this definition, then yes, a coding review serves very much the same function as QA, which is to scrutinize and improve the code.

Thus, the question shifts entirely to a new focus: Does code review fall under the departmental umbrella of QA?

It's Really A Matter Of How Agile You Are

Once again, the answer is, it depends. In a waterfall development environment, code review might be exclusive to developers as a way to sort of workshop their coding, or to spot any potential issues before sending the deliverable off to QA. Meanwhile, the siloed QA management team may be doing a similar code review of its own for the sake of assessing its test cases.

In an agile environment, on the other hand, there tends to be much more interdepartmental collaboration. Agile test management would include automation integration, and real-time sharing of project progress and testing metrics. In this type of environment, code review would undoubtedly be considered part of QA, departmentally and in practice.

In conclusion, the answer to the title question technically depends. However, as software development continues to become more complex, prompting greater interdepartmental collaboration, the answer gravitates much more significantly toward a resounding yes.