There are some great names among the founders of the still-nascent field, industry, and profession of Software Testing & Quality Assurance: Dave Gelperin, Boris Beizer, Glenford Myers, Rick Craig, and Lee Copeland, to name a few. A name not often included in that list is Michel Foucault. That may be because Foucault was a social theorist and philosopher rather than a software quality practitioner. But I was listening to a Foucault interview on knowledge and culture from 1971, and as with all things interesting, I started thinking how it might relate to QA.
Foucault argues that by acknowledging other cultures, identifying them, labeling them, we automatically separate them from our own. We accentuate the different, and cordon off the separate entities. From the point of view of a person in one culture, all the other cultures are outside, even a level below, in our typical way of thinking. It is a natural extension of individualizing ourselves, and seeing others as…other.
Foucault extends this insight into the way scientists identify and label different scientific disciplines. Long ago, all sciences were subsets of one integrated body of knowledge called “philosophy.” Hence, even today you get a Doctor of Philosophy or Ph.D. in many different areas like biology, physics, math, economics, literature, or even philosophy. But today we barely think of them all as subsets of philosophy. Every area is more differentiated than ever, with greater specialization than ever.
This tendency of separating, labeling, and specializing reminded me of the disciplines labeled “software development” (SD) versus “quality assurance” (QA). When you are a member of one, you differentiate from the other. But thought leaders and most successful practitioners argue for less separation, and more integration, of these two areas. SD should be infused with QA practices such that you would have a hard time seeing where one ends and the other begins.
QA-minded SD puts QA knowledge into the future-project team before it’s a project. A QA perspective in initial planning and assessments can improve your long-term succeed/fail ratio. Integrating QA into the conversation of what the project is supposed to accomplish, helps get all the pieces together between customer, business, and technical requirements, which reduces error rates later. QA participates in storyboarding, design, as well as functionality. QA-minded SD managers are open to code reviews of varying formality depending on context, which reduces error rates. QA-minded test managers (some are not!) go way beyond use cases, to every permutation of customer, business, and technical implications.
It’s all about every way possible to give the customer what’s expected and reduce error rates. That’s why it’s good to apply some Foucauldian epistemology and deconstruct the culture of SDLC.
The totally non-Foucauldian SD practice keeps a wall between SD and QA, where programmers huddle in a corner cranking out code, then toss the code over the wall for testers to catch what they can. But it’s not just not Foucauldian, it’s also not likely to produce a happy ending. The toss-over-the-wall approach will only get you the SDDC, or the Software Development Death Cycle, instead of a dynamic, vibrant, animated SDLC, a happy and successful Software Development Lifecycle.
There’s some sound advice that is completely different from what Foucault was talking about, which is exactly what he meant: In work as in life, break the culture barrier to improve product quality.