One of my favorite terms is "security theatre", coined by security expert Bruce Schneier and described at length in his excellent book Beyond Fear. Simply put, security theatre is the carrying out of actions which are designed to look as if they improve security while, at best, failing to improve security and, at worst, actually decreasing security.

Borrowing and twisting Schneier's terminology, I see a lot of quality theatre in the world of software development. No, I don't mean that programmers are performing Shakespeare; I mean that there are many people engaged in what is commonly called quality assurance (QA) who are not only failing to improve the quality of the end product, but who are actually decreasing the quality through their actions.

My company tends to work in heavily regulated industries such as the pharmaceutical industry, and in those industries software development must adhere to certain guidelines. The root motivation for those guidelines is to ensure the stability, accuracy, and repeatability of results with the completed software.

Mistaking quantity for quality, the individuals responsible for QA in these organizations tend to build elaborate sets of practices and procedures that produce reams of output (you've experienced this if someone you know has ever pointed to a shelf full of binders and beamed with pride as he said, "There's our test results!") Over time, these practices become more elaborate and byzantine while the QA representatives responsible for implementing them become more and more distant from the root motivation of better software. Since many skilled QA people are chosen because of their attention to detail rather than their broad vision, they tend not to question the way things are done. The end result: quality theatre, the blind adherence to a set of rituals which give the appearance of quality assurance while not actually contributing to the quality of the final product.

Some signs and examples of quality theatre:

• An emphasis on after-the-fact testing, with no preemptive quality assurance such as design or code reviews.
• Time-consuming, paper-generating rituals (such as taking a screen print of every test step) that don't have an observable benefit.
• Test scripts that exhaustively test unlikely conditions while lightly examining commonly-used features.

Have you seen examples of quality theatre? If so, add a comment. In a future post I'll talk about stripping out the theatre and ensuring that your QA actually improves quality.