The variety of configurations (operating system, browser, language etc.) can look overwhelming; and it is impossible to test all possible configurations for Servers and Clients. On the other hand there are certain platforms that are more probable to uncover defects.

This is just common sense, but I haven’t seen any terminology for handling this in an effecient manner, so let’s call it BCM.
Basic Configuration Matrix is a short list of platform configurations that will spot most of the platform bugs that could exist in your currently supported configuration matrix.

The simplest example is to use one configuration with the oldest supported operating system, oldest browser etc; and one configuration with the newest of all related software. A more advanced example could use several configurations that use different languages, Application Servers, authentication methods et.al.

If it would take too long to run most tests on BCM; alternate between the configurations while testing your product. Do variations on configurations when appropriate.

I have a friend that proof-reads every bug report before reporting; “otherwise there will be spelling errors”, she says.
I have a friend that always reproduces the bug before reporting it, at least four times.
I have friends that always ask “Bug or Feature?” or “One or two bugs?” when they are uncertain.
I have friends that look beyond each symptom to see if there are more serious errors as well, or if the same type of issue exists elsewhere.

I have a friend that tests the whole area so each bug report can contain all important information, but another friend reports every bug at once, so others get the information fast.
I have a friend that does everything possible to not report Duplicate, As Designed, Not Repro bugs; but another friend thinks that the occasional As Designed issue is a sign of taking responsibility.
I have a friend that focus most on formulating really good titles since they will be read by many, but another one focus on making sure the bug contains as much extra information as possible for the developers.
I have a friend that sometimes makes sure that the report contains only the necessary information; but sometimes puts the issue in a scenario context so the importance is clear.

Bug reports are our most deliverable and our best knowledge base.
And remember what they say in Starship Troopers: “The only good bug is a dead bug”

I just moved my profile to another domain, which meant I had to setup my Vista machine again.
Besides stuff that makes the computer usable (show all files, don’t hide file name extensions etc.), I try to create many possibilities for software to fail.
You know, a good tester is often lucky…

* run as Restricted User
* use Large DPI setting
* use German Regional Settings
* install support for all of the worlds characters
* non-English language in Internet Browsers
* move system and user Temp folder
* activate IE: ‘display a notification about every script error’
* move Task Bar to the left side of the screen
* Windows Classic Theme & Color Scheme
* use Vista User Access Control
* use an HTTP proxy
* use Data Execution Prevention
* install new versions as they come, e.g. latest hotfixes, MDAC etc.
* never install software on default location

And if you have the possibility, run with 2 screens, on a 64-bit system and with any other settings that might affect your software.

This is a good complement to your test machines; image system and BCM (Basic Configuration Matrix)