Mikey,

I'm reading this test chapter, and it's pretty good. I do have some feedback for you, would you rather I post it here, or mark up the chapter and send it to you?

Update: I marked up the chapter in Word. It's probably too big to send to you while you're on the road, downloading in a cafe or whatnot. Tell me how you want it, and I'll send it along.

No go on uploading the chapter, Mike- the max attachment size is a piddly 20kb, or 1/21 of the size of this doc.

So, I've opened the .doc and grabbed my comments. Not the best way to review a doc, but what the hell:


An observation about reproducing bugs, and your definition: its often more about a particular set of accidental, or incidental, circumstances that cause a bug to be produced, not a specific procedure- and it doesnt have to be the tester that reproduces it, it can be anyone, as long as they know how they did it and can do it again.

In the next paragraph, If the team could not reproduce a bug is more direct action, and better describes real usage of this term. Just being picky.

I think this (albiet) is a syn. for but, and not correct when not preceded by an adjective or other object.

You really should mention integration testing, as more and more games have a multiplayer component that will require interfacing with software and systems external to your code.

I assume that Guerrilla testing is the same as Stress testing: aka negative testing, everything that you can reasonably expect a user to do wrong. Tests error handling. Your description of stress testing is all hardware!

Other types of testing which may or may not be applicable in a game setting: performance testing; regression testing.

When the developer writes add-on functionality or a stand alone program that would not otherwise be in the code for the explicit purpose of testing functionality, this is called a test harness. I believe thats what youre describing here. Its separate, but often related, to automated testing.

When possible, a bug will also include a screenshot!

If working from a test case, as a tester should be, then the expected results are already there.

Deferred is a much more manager/business/customer-friendly term than Wont Fix(!)

This would be the life of a simple bug, as opposed to one where the testers verification didnt show the bug resolved, or it created another defect.

Dood, you completely left out anything about writing test cases. I know that this book is written for developers, and the test team should write the cases, not the dev team, and that test case writing could be a whole chapter (or book!) to itself, but everyone should know a little basic something about it- it helps when you write the other docs, like the design docs (Functional Specification or Software Requirements Specification)