One thing I can claim to know: as any company continues to grow its quality practices (not just its test practices), its challenges will grow. One of those challenges will be making sure that the company can operate in a so-called “agile” fashion while still building a solid base of actionable knowledge related to quality and testing. So let’s talk about that.

In order to focus the discussion a bit, let me throw out a few points that are opinions I hold.

• There are different types of knowledge and that means there are various approaches and techniques should be used for the knowledge being dealt with.
• There are different ways of representing knowledge. Those ways can aid the acquisition, validation, and re-use of knowledge.
• There are different ways of using knowledge and that means that the acquisition process should be guided by the contextual and situational aims of various projects.

One of the most pernicious problems I deal with as a tester is that environments keep falling into gedächtniskulturen (or “culture of memory”, if you prefer). I, as a professional tester and general gadfly, like focus on a procedure called the “dethronement of memory.” (This is the same procedure that happened when the printing press was invented and things moved from oral tradition to written transmission.) Whatever the benefits of memory, it doesn’t pay to have it be the major — and certainly not the sole — repository of knowledge.

The same concept is known in the business world as “de-institutionalizing knowledge.” That just means that you should avoid treating knowledge as something that is institutionalized in a given set of people. Rather, you should work to distribute the knowledge in such a way that it’s available to everyone. Further, that knowledge is available in such a way that people have a reasonable chance of actually finding what they need and being able to increase the store of knowledge in their own way.

When I talked previously about inventors on test teams I mentioned “localized regions of knowledge — areas of specialization, islands of sophistication.” Those localized regions are exactly what I’m talking about and they easily form. So this is all about capturing and distributing knowledge. Those who read me rambling about tests as specifications will probably realize that I feel knowledge can be codified as tests. Those tests can be used in a variety of ways. They can serve as one form of documentation. They can serve as a guide to development. They can serve as feature descriptions for business analysts or marketing. They can serve as training material for new testers or developers.

But I’m getting ahead of myself here. I’m throwing out a solution before I’m sure people even agree to the problem. So let’s back up.

Among historians there’s some doubt about whether a guy named “Confucius” actually existed. But one of the sayings attributed to him is “Real knowledge is to know the extent of one’s ignorance.” Whether that guy said that statement, I believe it’s a true statement. I think that’s one of the benefits of having some sort of repository of knowledge. While the repository can showcase what you know, it also, by the very presence of what you’ve accumulated, highlights the borders beyond which ignorance still holds sway. So that means the repository points the way to more learning and thus more questioning and thus more thinking.

(Hey, wait! Doesn’t that sound like what a test repository is?)

Now consider this little bit of wisdom: “To be master of any branch of knowledge, you must master those which lie next to it; and thus to know anything you must know all.” That’s not from me. That was from Oliver Wendell Holmes. I’ve found that this thought is at least partially true for me, particularly in a field like quality assurance or software development. You don’t have to know “all” (nor, would I argue, can you) but you do have to have a little knowledge of just about everything. Clearly what that means in terms of how much people must know will differ. At one point, I talked about test teams needing inventors. Here’s where I tie that to something useful. I think the notion of what a quality team needs to invent will often dictate how much everyone needs to know. It’s an organic process that forces you to learn just enough to invent what you need right now, but certainly doesn’t stop you from learning even more.

So let me try to be moderately relevant here: quality guy W. Edwards Deming. Remember him? He said “best efforts will not substitute for knowledge.” That’s something else that I believe is most definitely true. The point there is that the collective “we” — a quality-focused development organization — can’t just assume that if we “do our best” we will somehow be effective. Ultimately we have to capture what we do to the extent that we’re able. If you’ve ever read the Bhagavad-gita (in the part entitled “The Perfection of Renunciation”), it talks about knowledge (jnana) and action (karma) and it says something that’s always stuck with me:

“The wise see knowledge and action as one; they see truly.”

I take that to mean that knowledge leads to action and action feeds into gaining more knowledge. If that’s true — and I believe it is — then there are very practical reasons to capture knowledge beyond just the ability to say we do it. Those practical reasons are that we can use that knowledge to guide our day-to-day actions and give us a solid base upon which to present ourselves and our strategies to other people, whether that be sales, support, or our various clients. This is part of the basis for knowledge engineering: actionable knowledge and actionable knowledge filters. The filters are what allow us to selectively navigate our knowledge and determine which parts of it are relevant for a given situation.

So here’s where I pretend I had a point all along. All of this is part of what a knowledge engineering effort has to put in place:

1. You foster a team of inventors that build a base.
2. That base will be the tactics that drive your day-to-day actions.
3. When those tactics are wedded into a whole that provides meaning and insight.
4. That meaning and insight are the basis of your strategy.
5. That strategy is what you build up over time as your knowledge grows.
6. That growth in knowledge is what allows you to build products under a shared notion of quality.

Knowledge engineering? Who handles that? The test team? No, I would argue that is the mandate of a quality assurance function. (I do not say a quality assurance team, per se. See my thoughts on “obvious” quality assurance.) But given that a “QA team” tends to either fall out of or be mistaken for a test team, I think a test team can be a good place to start the ball rolling. That’s why this post is titled the way it is.

One last point. I think all of this is what allows a company to effectively act agile (because you know you don’t have all knowledge) and also with process (because you know you have to capture what knowledge you don’t have). Notice a key point there: you can have agility and process. They’re not an either-or even though sometimes people treat them as if they were.

As a final note, going back to that solution: I encourage testers to think about the ideas around “tests as specifications.” And while doing so, treat the term “specification” as a broad term and a multi-faceted work product.