Select Mode

About Tester Stories

This blog captures my stories. I’m engaged here in the process of encoding thought and experience into a form of media: a vehicle of expression that allows the self to do some shaping but that also acts to shape the self. A fluid relationship. The medium becomes part of the message, not just the conveyor. What you’ll find here is what I consider conceptual diamonds, forged from thoughts pressed hard. The goal is to make sure the center of gravity shifts back and forth between theory and practice. Along the way I’m essentially promoting an invented sense of self because I believe that what’s all testers do as they come to grips with their discipline. Obviously my focus here is on the arena of software testing. A thread that will run through these stories, like a high-tensile steel cable, is the idea of quality. My focus isn’t on quality itself, though, because quality is not a thing; it’s the measure of a thing. But what is it a measure of? I think it’s a measure of balance — that is, the right proportions of the correct ingredients. So what’s this balance we’re measuring? I think that quality is getting the right balance between timeliness to market, price to cost, feature richness, reliability, and support to achieve whatever your customers want you to achieve. Then what are the ingredients? Well, that’s where having a diverse background in testing comes in. Any effort at testing must exist in balance with all of those factors I just mentioned. This means that testers need tools that will allow them to capture business knowledge. Testers need tools that can keep up with development. Most importantly, testers need the knowledge to use all these tools. The good news is that there are lots of tools out there that can help do the job. The bad news is that it can be a rough slog figuring out which ones are out there, which work, and how well they work. Coupled with this is the fact that tools, by themselves, don’t do anything. It’s the input of a trained tester that makes the tools do what needs to be done. And there’s really very little out there that teaches this or even explains a lot of it in a way that I’ve found useful from the standpoint of the tester with the non-development background but who has to certainly operate as a technical resource within a software project.