If you want to be good at software testing, read this. Take it to work with you. Refer to it often.

by Kristin Miltner
(Oakland, CA)

Working on audio for games, I am often testing my own audio, since testing departments are rarely sufficiently staffed to take on audio bugs besides 'is this asset in the design doc playing in the build?' For me, this has involved gradually building bug writing skills so that engineers can implement my audio properly. Imagine my surprise when I found the things I had learned by trial and error over years of practice clearly and succinctly outlined for me in the pages of Phil's book.

When I decided to get back into QA to expand my skill set after years of audio production, I thought: "How am I going to brush up on my testing skills, and ensure that interviewers know I am committed and knowledgeable, especially after a gap in my resume where I did not work in a testing department?' Then I found Phil's book. I prepared for my interviews, using Phil's book to refresh my vocabulary, jog my memory and get me current.

I realized upon reading this book that not only could I have used it when I was first hired as a tester of audio hardware many years ago, it has also assured me that I have been doing some things right in my daily practice. It has located areas where I could be stronger. It has given me insight into the current expectations and qualifications of my tester colleagues down the hall or in an office on the other side of town, as I build audio for a project. This makes it easier for QA to work with me, which in turn makes my job easier.

There are many pieces of essential advice in this book. As a software tester, I was often concerned that I may be spending too much time eliminating variables or chasing elusive bugs, but this book confirmed that if I didn't spend the time, it costs the company time and money in the long run, and if you always document what you are doing, you might not come to the conclusion you expected, but you will inevitably learn something about the bug. I very much appreciated the emphasis on proper and methodical documentation, and specificity in writing as an invaluable tool and congenial shield against engineers that don't wanna hear it.

Also, I should mention that the casual tone of this book brings what could be a pretty dry subject to life. I am so glad I came across it, only wish I would have sooner. After working in both waterfall and Agile production teams, I finally got the clearest explanation of them both, comparatively, from Phil!