All testers create a mental model of the product under test - it's just what we do. And different types of testers come up with different types of models - that is only to be expected. But many aspects of the testing process work best with a certain type of model - make sure you use the right one (aka the right person) for that task.

Some folks, notably those with a development background, come up with a functional or architectural model - hopefully one that matches the actual structure of the code. These people are good for coverage tests, and identifying areas of risk given a proposed code change. But they are not the ones best at getting inside the minds of the end users. They often feel a portion of the product is important because it is called from lots of other locations in the code, regardless of how many times it is called during actual use of the product by an end-user.

Some folks come up with functional models that do not match how stuff actually looks under-the-hood. Think "Rube Goldberg" or magic. They are useful because - if their models are consistent - they will find bugs that neither the developers nor the subject-matter experts will think of. CS folks know of the user who is absolutely sure he knows how to fix the problem because he has "intuited" the inner workings of the product - never mind the fact that he is dead wrong. Having a tester who makes this kind of model is like having one of these customers on-staff, but in a good way as they will find the bugs that will be found by the challenging customers. But don't let them be in charge of code-coverage testing.

Still others make use-models. Subject-matter experts are like this - they can measure the product's behaviour against what the users will expect. These folks are great for usability tests (obviously) and functional spec reviews, but not as good at coming up with stress tests or measuring performance. (I'm not exactly sure why this is)

And yet others make incredibly wacky, almost incomprehensible models. Don't put them in charge, but make sure you have at least one of these types around because they challenge your every assumption about the product and keep you on your toes.  2:20:05 PM    

A quick search on google for "QA", limited to radio.weblogs.com, reveals my stuff, plus one day's posting from lawrence.

The only QA blog I was aware of was The Bug Hunter, and it is no longer being updated.  10:40:15 AM