Stefan Kläner commented on my last blog entry saying:

But an inspection for me is a somewhat regular process. Like state authorities would inspect restaurants to make sure they work according to certain standards, or an internal check if your company fulfills all FDA requirements before an FDA audit.
So in my opinion inspection would be a repetitive task. To stay at your windshield-example (which I like), you would inspect it in the morning, to check if it is frozen or not. Obviously you wouldn’t inspect in in the summer, that’s why I wrote “somewhat regular” as it is usely triggered by an event.

In order to answer the question, I have to get back to my initial inspiration, which is the book “How to read a book”.

On page 18 of this book, the authors give a brief overview of what consists inspectional reading in the four level model of reading the authors follow within the whole book:

The second level of reading we will call Inspectional Reading. It is characterized by its special emphasis on time. When reading at this level, the student is allowed a set time to complete an assigned amount of reading. He might be allowed fifteen minutes to read this book, for instance – or even a book twice as long. [“How to read a book” has 419 pages – MG]
Hence another way to describe this level of reading is to say that its aim is to get the most out of a book within a given time – usually a relatively short time, and always (by definition) too short a time to get out of the book everything that can be gotten.
Still another name for this level might be skimming or pre-reading. However, we do not mean the kind of skimming that is characterized by casual or random browsing through a book. Inspectional reading is the art of skimming systematically.
When reading at this level, your aim is to examine the surface of the book, to learn everything, that the surface alone can teach you. That is often a good deal.
Whereas the question that is asked at the first level is “What does the sentence say?” the question typically asked at this level is “What is the book about?” That is a surface question; others of a similar nature are “What is the structure of the book?” or “What are its parts?”
Upon completing an inspectional reading of a book, no matter how short the time you had to do it in, you should also be able to answer the question, “What kind of book is it – a novel, a history, a scientific treatise?”

(How to Read a book – Mortimer Adler, Charles Van Doren)

In the excerpt above please notice that you can exchange easily the words around reading and books with testing and software, and yet still receive a similar meaning.

With Inspectional Testing we want to find out what the product is about, what its purpose is, and what value it should provide to the customer. We want to find out within a relatively short period of time what the product does, and which areas we want to focus on later – in later charters.

Please also note that Inspectional Testing is not poking around with the keys at the product. It’s about finding out what the product does, and what it doesn’t in a structured manner. We want to get a high overview quickly, so that we are able to tackle risks of our testing process fast with follow-up charters. We take into consideration the opportunity costs of testing – that is any test that we run today accompanies for other test that we cannot run during this time.

Also note the difference to what I call Elementary Testing (to keep the analogy to the first level of reading) which is taught by more traditional testing courses like ISTQB or ISEB. Please also note that you cannot test at the Inspectionally without the elementary knowledge of what testing is about. Oh, sure, you can do that, but that’s not Inspectional Testing. More on this in a later blog entry maybe.

To sum up, Inspectional Testing is about managing time well. We want a quick understanding of the application in order to find out quickly on which areas we will have to focus during follow-up sessions. We will have to do that in a skilled manner using any techniques that come to mind. We do this with the underlying assumption that complete is never possible, and that we have an incomplete model of the application in question, and want to extend that model.