In my last post I mentioned that "QA can be seen as an excellent example of a posteriori knowledge" and that it could reinforce arguments against a priori knowledge.
So lets start with the idea of the a priori. Put in very simple terms, this is knowledge you gain before (or prior to) experience. Philosophers like Kant* and Plato believed that there were just certain things you knew -- you didn't have to live through them to know what they were. For Plato, concepts like Love and Justice were gained a priori.
A posteriori knowledge, on the other hand, is the knowledge that must be experienced in order to be gained; knowledge comes post-experience, so to speak.
And how does any of this relate to quality assurance? Well, QA is a great real-life example of a priori vs. a posteriori knowledge.
Say, for example, you have a specification -- we'll use product spec here, but it can be any number of specifications -- feature, design, whatever. So in your product spec, there is a combination of broad and specific product features -- the things you believe the product should do. You can't detail every single action possible in every feature because you just can't know beforehand that everything will work, or, sometimes, even how. A product spec is generally written before anything gets built -- it is done a priori, because you have no experience of the actual product itself yet.
As soon as your product is in the build process, you can begin testing. Presumably, you're using a priori knowledge (the spec, in this case) as your basis, but upon closer investigation – or testing – you find that Feature X requires significantly more work (and therefore time and money) than what was planned. Your choice now includes either re-thinking your features/requirements or coming up with a new plan to accommodate for the additional time and budget that's needed.
That's one broad QA example. Another, more specific example would be the way that QA testing itself is done.
Let's say you think you found a bug. Unless that bug is reproducible, i.e., you can invoke that issue consistently each time you perform a particular action, and more importantly, OTHERS can consistently invoke that particular issue each time they perform a specific action – then it can't be considered a bug. Without its being reproducible, you're still in the a priori. You don't actually have (a posteriori) experience of it until you can see that bug and document the steps to get to it. Until then, you really don't Know.
Epistemelogically speaking, and in terms of software testing, we're asking the question: How do you know?
If we answer in the a priori, we'd say, “Because that's what the spec says.” But once your software begins its testing cycle, you can answer in the a posteriori: “Because we did x, then y, then z and we got this result.”
QA is a good real-life example of a posteriori knowledge because it is only through testing that we can Know.
---------------------------------------------------------
*Actually, Kant classified knowledge into: a priori, empirical (aka, a posteriori), analytic and synthetic. It all gets very complicated and confusing, and I admit that I am over-simplifying here for argument's sake.
