SQA and Agile Methodologies

In 1993 I did an SQA (software quality assurance) course at UTS (University of Technology, Sydney).  This got me thinking about things like development methodologies, software design etc and ultimately resulted in this blog.

Since that time the idea (or at least the term) QA in software development has become very popular.  The problem is that for most companies QA is just a fancy term for testing.  In reality, QA (quality assurance) has little to do with post-production inspection (ie testing).  Now, I am not trying to denigrate test teams as they perform a valuable service and generally do a good job of what is a tedious task, but testing is not QA.  At best it is a QC (quality control) procedure.

So what is SQA?  SQA is mainly based on ideas from mainstream QA so I will explain QA before getting into the specifics of SQA.  Later I look at an apparently irreconcilable difference between SQA and agile methodologies.

Principles of QA

Process Improvement

The emphasis in QA is on the process not the product.  For example, many years of production line experience have shown that inspecting the end product for defects is much less efficient (and more error-prone) than concentrating on improving the process that creates the product.

The QA emphasis is on doing things right first time.  That is, eliminating problems in the process will reduce defects and rework, with consequent improvements in quality and productivity.  This is based on the adage "prevention is better than cure".

Further, everyone is responsible for quality not a specialized QA team (though a QA team may be responsible for training and monitoring of quality).  The target is to have zero defects through continuous improvement of the process.

Cultural change

It is well recognized that a commitment to quality by all employees requires a large cultural change in many organizations.  (Remember quality is everyone's responsibility.)  Of course, the culture of any organization starts from the top, so it is important that senior management is committed to this cultural change and empowers people to make the changes.

Customer Focus

The focus is always on the customer (ie, the end user of whatever is being produced).  All employees should have an awareness of, if not direct interaction with, the actual users of the product.  Feedback from the customer is encouraged.  Employees whose job affects the customer (ie, everyone) should not be insulated from them by layers of bureaucracy.

Quality is the always seen as suitability of the product for the customer's use, not how many bells and whistles it has.  Further, the emphasis is always giving the customer what they need, not trying to make as much money out of them as possible.  (Similarly, it's better to build a partnership with suppliers than try to milk them for the lowest price for their services.)

When all employees have a clear focus on the customer, they will work together towards the common goal.

Another aspect, is that most employees have internal customers - those people who directly depend on what they do.  Providing a good service to internal customers is also important.

Empowerment

QA promotes a management style where all employees are empowered to make decisions to improve the work that they do.  They are provided with the information and equipment to do their job properly.  Most important is to drive out fear, for example, of making a mistake or not reaching production quotas.

Communication between the workers is important, in order to have a clear understanding of their common goal.  Barriers to communication include things like performance appraisals (which essentially promote competition not cooperation), and anything that promotes fear.

Also, employees are given training to perform their work or to take up new positions and self-improvement is encouraged.  

Techniques

There are many techniques associated with QA (and SQA) but one specific approach is the idea that related processes should be kept as close as possible to each other, especially in time.  For example, if a process is performed before it is needed then when it is eventually needed it is more likely to be incorrect (and require rework).  Furthermore, people's memories of the process are not fresh which can cause delays and further mistakes.  One example is the idea of JIT (just in time) from Japan.

SQA

SQA (software quality assurance) is essentially the same as QA but with emphasis on specific areas and the addition of a few techniques appropriate to software development.

First, the emphasis on improving the process is even more important for software.  Studies show that testing finds, at best, 30% of bugs.  Any programmer can confirm that there are so many possible permutations in the use of even a simple piece of software that it is impossible to test using a black box (ie post-production) approach.

Further, the quality of the software is not just related to what the user sees but also to the effect on developer quality attributes (see my post: Developer Quality Attributes).  A programmer needs to remember that whoever ends up maintaining her code is her internal customer.

Finally, there are specific techniques promoted in SQA that are based on QA principles.  For example, code reviews are a means of process improvement and a means of improving communication.  Further many agile techniques come directly from QA principles (see below).

SQA vs Agile

When I was first introduced to Extreme Programming (XP) by a colleague about 12 years ago (thanks Sam), I dismissed it as just a rehashing of SQA principles.  Admittedly there are a lot of similarities such as customer focus and feedback, empowerment, communication and especially emphasis on improving the development process.  Even the idea of YAGNI (you ain't gonna need it) is related to the QA idea of not doing something until it is needed - which is probably why it is also called JIT-design.  (Testing also benefits from the idea - see my post: JIT Testing).

However there is one glaring difference: SQA emphasizes doing things right first time, whereas agile relies on iterative refinement.  XP, and agile methodologies, in general say that you can never get the design of a large piece of software right the first time.

So which is correct?

I believe that in this case agile is correct but in general the QA principle of right first time is sound.  Software design is an exception that proves the rule.  Many of the techniques of agile actually support the idea of right first time since they are about avoiding errors and doing things properly.  For example, unit tests (popularized by agile methodologies) are incredibly useful for reducing defects (among other things) with reduced rework (bug fixing) and increased quality and productivity.

It is simply that it is often impossible to get the design of software correct on the first try no matter how hard you try.  The iterative approach of agile is not an abandonment of right first time but an attempt to get the design right as soon as possible.  It also improves the process and gets the customer more involved which are both fundamentals of QA.

Conclusion

Just a few simple points here:

1. QA in software is not about testing but about building quality into the product.

2. Agile methodologies are based on SQA principles more than most people realize.

3. Right First Time is not anathema to the agile approach.