Let’s take a look at the definition of SQA from Wikipedia (http://en.wikipedia.org/wiki/Software_quality_assurance)
“Software quality assurance (SQA) consists of a means of monitoring the software engineering processes and methods used to ensure quality. The methods by which this is accomplished are many and varied, and may include ensuring conformance to one or more standards, such as ISO 9000 or CMMI.”

This definition is concentrated on monitoring the process and conformance to standards (or maybe I take it wrong?).

Yes, I tried to describe that maintaining quality is sometimes more than monitoring the process.

Thanks for stopping by.

Very good article! I liked it!

Although, I would not call “Software Quality Assurance” a bad term. In fact, this term has nothing to do with process quality, the software quality is what it is referring to. However, the means of maintaining the quality can be different. I guess this is what this post is about.

I believe, these techniques can be used in project of almost any scale.

For instance, code review came from formal inspection of big systems, although it has got lighter and less formal.

Of course, it doesn’t make sense to involve entire team into review of every single part. You can involve peers from your sub-team, who have at least some understanding of part to be reviewed. And if nobody understands what you have done then you become single point of failure - it means that this code can result into failure of the entire application. Or in case of a person’s leaving no-one knows anything about their work - that’s huge risk. I don’t think that it’s acceptable for the business.

These techniques should be scaled to match context - if needed they should become more formal, less frequent, not involving entire team and taking into account other factors of project’s environment. Or the project may not use them at all if they don’t provide enough value.