I’ve worked with lots of testers who often take on more work than they should because they have the idea that the work they are taking on is what testers should be doing. It’s often not a question of whether they should do this work given their other constraints, but rather just a focus on how they can regardless of those constraints. Granted, many companies seem to foster this by job descriptions that suggest someone needs to be a developer, DBA, business analyst, and tester all in one. A main aspect of my job description as a quality assurance and test practitioner comes down to defining a role, usually separate from the relatively anodyne job descriptions we’re all used to.

My role, as I see it, is to educate people on what it means to test and how quality is a contextual and situational term that testing, by itself, won’t help anyone define. Further, my role (or my job description, as I would write it) can be broken down quite simply.

What’s my job? My job as a tester is to become a credible reporter of empirical information that people value because it helps them make informed business and technical decisions.

Simple, but far from easy.

Obviously the devil is very much in the details here but, as you can see, this description leaves me open to define a role as I see fit, while still allowing checks and balances on what I do. After all, if people don’t think I provide empirical information, then I’m failing in that part of my job. If my information is not credible, again, I’m not doing so hot. If people find they can’t make decisions based on what I provide to them, well … you see the pattern.

I’ve found that nailing down an internal role description too specifically beyond what I’ve just said isn’t helpful. I’ll say that again: nailing down your job description to every nuance is not helpful!

What’s my value? I feel that my greatest asset to a company is my internalized values, my experience (which shaped my values), and my ability to think about solutions and implement those solutions that make the most sense given the context and situation.

That set of aspects is hard to nail down in a specific role and/or job description so I don’t try. Usually what I do, when asked to define my own role, is provide what I just said here as a type of charter, but then also give some idea of what specific practices and techniques I follow.

This all sounds great … until you realize that my definitions sometimes can be seen as either controversial or confusing. (I’m not sure which is better.) A lot of that controversy/confusion has to do with expectations. By this I mean that what people thought they knew and understood about testing are concepts that I often challenge. In case you’re wondering where I’m going with this, all of what I just said has direct relevance on the umbrella of activities I can do.

What’s my umbrella? The “umbrella” of activities that I can reasonably take on is often dictated by my values, which I encapsulate in my strategy.

I’m not talking “test strategy” here, but the more overarching Strategy. (Note that capital ‘S’ and imagine that word being said with a neat echo-and-reverb sound effect and you’ll get the idea.) What I tell people is that my strategy always works relative to given constraints and resources but it also works based on a core set of values. That core set of values makes the strategy pretty rigid.

Here’s how I look at it and present it: any test team needs to be sure that all activities of the test effort are adequate and properly executed. If they can’t do that, they shouldn’t be doing the activity. Perhaps it’s a resource problem. Perhaps it’s a tool problem. Perhaps it’s some other constraint. But the point is that if I can’t adequately do something in a proper way, then even if it should be under my “umbrella” of activities, it can’t be for now.

Here’s how I frame that in questions when deciding what to take on and what I have to hold off on:

• How much of the thing I’m being asked to do can I do adequately?
• Can I control the activity adequately enough to allow it to give me useful information?
• Can I measure the activity adequately enough to allow others to use the information to make decisions?

What does “adequate” mean, though?

This comes down to the goal of the test effort. This goal is not so much to determine what is and what isn’t of value in the product or service I’m testing. That’s ultimately a business decision.

What’s my goal? The goal of my test effort is to provide enough information to help people make informed decisions about whether the value they believe is necessary for success does, in fact, exist.

If I believe something will stop me from doing that — and doing that accurately (precision), efficiently (within resources), and effectively (in reasonable time) — then I bring that up and I show why I believe that.

This helps me set expectations of not only what my role currently is but the way in which my role can potentially evolve as the scope of what I am able to do changes. It also allows me to show people that my goal is not “quality assurance,” at least not all by its lonesome. Rather, my goal — and the basis of my strategy — is to determine what the agreed upon notion of quality means for a given project/product and then perform enough investigation to allow others to determine if that quality is present or is lacking.