Wherein one weeps over the inferiority complexes of one’s peers….
I’ve been reading, I’ve been writing, and I’ve been working. And a great deal of what I’ve been reading lately disturbs me. We have some really great minds in this field; how much time are they going to waste word-smithing our “mission”? And what makes anyone think the latest definitions are good or distinguish the testing field from any other group on a given project? Here’s a prime example, from a discussion on the forums at the Software Testing Club; no offense is directed at anyone involved in that particular conversation – I chose it because it’s pretty much indicative of a variety of conversations going on about the same topic:
"To provide correct and timely visibility into the product and process, in order to help the organization and its stakeholders make tactical and strategic decisions; and to do this as close as possible to the defined constraints of schedule, functionality and costs."
OK, so what’s wrong with this? Nothing, I suppose. It could also be the mission statement of virtually anyone on a project team, including finance.
EVERYONE on a project team helps provide visibility into the product and process. EVERYONE provides information to help a given organization and/or its stakeholders make decisions.
So what makes QA/QC different?
We provide those insights based on our testing experiences.
I do not see anything in the provided definition that mentions this distinction. Perhaps it would be of more benefit to the field to step up and be proud of what you do and stop trying to find fancy ways to avoid mentioning the word “test”.
C’mon! Are you a tester? Isn’t it the GREATEST JOB ON EARTH? So why are we acting like a bunch of sad, little monkeys struggling for recognition? I think it’s time to walk upright without our knuckles dragging on the ground; we should have evolved that far by now. You’re an expert professional. You should be looking everyone straight in the eye.
Why do some people feel such an overwhelming need to make our field sound more important? It’s a sign of insecurity. We’re already important. But if we, as professionals, don’t believe that and have to convince ourselves, it’s that much harder to convince anyone else. It’s easier to “sell” what you believe in yourself. It’s easier to “sell” WHEN you believe in yourself.
How can you have a mission statement that doesn’t mention the word “test”? I’d expect that kind of poofy nonsense from a PM who wasn’t very good at his job, not a tester. And why are we STILL, as a field, so honking sensitive and insecure about what we do that we continue – AFTER 25 YEARS – to struggle to define ourselves in a way we think will get us some respect?
Maybe we need to respect ourselves first. Do developers agonize over this kind of stuff? DBAs? PMs?
Not so much.
I realize the thrust of these conversations is to bring awareness that our primary job (testing) provides information to decision-makers and stakeholders. That’s not Big News. Not to me, not to the rest of the field, and not to IT in general. I think it’s important to not lose sight of the fact that our primary job is “testing”. Without that, we’d just be chatting idly about the weather or playing cards with those decision-makers and stakeholders.
Where’s the pride in what we do and the contributions we make? The word “test” is beautimous. There’s no need to be ashamed of it and no need to avoid it. There is no one else on the project team with our mission and no one else on the project team that can fulfill it with the same passion, dedication, and level of expertise…
Attitude is everything. To get respect, you have to give it. To get respect, you have to have some for yourselves. And to get respect you have to earn it. Dorking about with mission statements written to impress CEOs with political bullshit is not the way to do that. They’re inundated with that kind of fertilizer every day. And I, personally, resent it when one of my own peers serves it to me on a platter and expects me to swallow it. I can’t even choke it down when it’s accompanied by an adult beverage and a straw.
So I’m making a plea to the word-smiths amongst us; we have no mission if it doesn’t involve “testing”. For those still struggling with recognition and who would benefit from a cohesive mission statement, let’s start with that basic truth and move on from there.
Friday, May 1, 2009
Subscribe to:
Post Comments (Atom)
Posts
4 comments:
Nice post. I like your general statement. I think the word-smithing comes in for those of us "stateside" managers who are trying to save our stateside colleagues. The question is always "I can get testing cheaper in (insert offshore). What value do you bring beyond testing?". The biggest thing you don't get offshore is process excellence and test plan maturity. How do you explain that to someone not in the testing trenches who wants nothing more than to prove to their manager the cost cutting they achieved that quarter?
I think the word-smithing is not hurtful as long as its not forgotten that testing is the means to an end.
I have the same issues. In fact, developers have the same issues as well.
I address them by talking about WHAT TYPE of testing services can be expected to be economical from offshore staff and WHAT TYPE of testing services are more cost-effective when kept on-site. That way, you are validating the opinion of the person that believes testing can be cheaper offshore, but modifying their expectations so that they understand what type of testing services they'd actually be purchasing.
I've personally been sucessful in moving repetitive execution tasks offshore and retaining analysis for new changes/updates/projects on-site. Why? Because of several of the statements you've already made. It's difficult to get expertise and maturity offshore; their market involves a lot of job-hopping and a constant influx of people new to the field. In addition, the language barriers, time differences, and difficulties working with specs that may be both complex and incomplete actually make it more efficient to handle new stuff on-site. What you might end up with is a mix of off-shore and on-site personnel, but overall you give a little and gain a lot -all with the goal of providing comprehensive testing services to your organization.
Furthermore, your manager (and up) regard you as a cooperative and forward-thinking manager that isn't trying to impede progress. Many managers don't realize that executive management regards managers that refuse or put up roadblocks to offshoring as immature. They're EXPECTING kickback from people who "can't see the big picture". When they get thoughtful negotiation based on experience and a genuine desire to provide value, their perceptions change.
But I have to say that from an executive management perspective, it's all still testing and a mission statement needs to include the entire mission, not just on-site (or offshore) activity.
So I'd still like to see the "testing" differentiator present in any mission statement; otherwise, it just appears to be double-talk and it's my belief a CEO can smell it a mile away. You're actually encouraging their antennae to go up and to be grilled as to what those ambiguous statements really mean.
Word-smithing is probably not hurtful; I have to in all honesty say that I am not the type of person who enjoys arguing, for example, for 3 hours about the difference between "verification" and "validation". It makes me want to pound my head against a wall until my brains leak out my ears. So I become impatient with activities that I do not perceive as especially useful, and I think this latest spate of mission statements that do not involve the word "testing" falls into that category.
Linda,
First of all, it’s nice to see one’s words quoted on someone else’s post, especially if the post comes from someone you respect. Still, I think that you missed the context of the words and thus their real meaning.
I wrote the definition you quoted in this post for the use of our own Testing Teams and the Stakeholders with whom we interact in a regular basis, and not as a mission statement to be printed in bright letters and posted in the walls in order to increase our Apparent Value in the eyes of a CEO or any other Company Executive. I don’t think a serious Testing Team should use such gimmicks to increase their value…
The definition is part of a concept I use called Testing Intelligence, and it comes from my work with testing teams as an internal Tester/Lead/Manager for over 10 years and lately in my 2 years as a consultant. During this time I’ve met too many teams and managers who don’t understand that the value of the QA comes from working with the Internal Stakeholders in order to provide them with visibility into the product and process; and not from fighting with development over a specific bug to fix or from explaining to the rest of the team why they cannot modify their test plans based on the changes in the project.
Testing Intelligence, as I use it in my posts and presentations (and notice that the word TESTING does appear, and I don’t think we should be ashamed of it!), helps me explain first of all to fellow Testers and Test Manager and later also to the Organization Stakeholders, that our tests need to provide INTELLIGENCE and Internal Visibility to the Organization in the same way that we have teams providing External Visibility to the organization with their Business Intelligence.
And in this point I disagree with you, since I don’t think that everybody in the organization is charged with providing product and project visibility like we are, and definitely not the finance teams that I know.
Maybe all this is not new for you or the teams you are in contact with. But I don’t think that all organizations are in the same place you are, and this reminder is something that is valuable to them.
I will also agree with you in two important things:
(1) The fact that I didn’t write the word TEST or TESTING in the body of the definition, and now that I review myself in a couple of replies in STC, may cause people to misinterpret it as you just did and I will correct this, THANKS for bringing it to my attention!
and
(2) There are too many people fighting over words and meanings already...
In any case, I am with you on the fact that we are Testing Professionals and we should not be ashamed of it. This is an important point, just not what I meant with what I wrote.
My 2 cents,
-joel
Joel, you somewhat missed my point; your definition was pulled because it is INDICATIVE of a great many other conversations going on at this time in regards to the same topic.
You said "And in this point I disagree with you, since I don’t think that everybody in the organization is charged with providing product and project visibility like we are, and definitely not the finance teams that I know.".
We'll have to agree to disagree on that one. Everyone on a project provides product and project visibility, and that does include finance at many companies. Test results are not the only factors that go into making intelligent decisions. You appear to differentiate between internal and external visibility; from a business perspective, it's all "intelligence", with financial/cost considerations usually weighted highest.
Consider that your testing might uncover some missed business requirements or specifications. You report the discovery. The BA and/or end users contribute their thoughts as to whether they absolutely need those changes, when, and what the changes need to do. The development team provides insight into the time, effort, and technical considerations involved with adding the requirements. Finance (or the PM) determines whether the project budget can support the extra work. The PM determines whether making the changes can be done without impacting critical schedules, and so on.
Overall, I'm not sure we can provide "intelligence" per se; we can provide information that can help an organization with their overall business intelligence strategies, but providing information, even if such information is excellent, does not guarantee intelligent use of that information.
I'd also like to mention it's my own opinion that a statement that says we provide "visibility into the product and process" is not really a clear statement. People who hear it will *think* they know what it means, but they won't be quite sure. "Provide information about the product and process through testing services" might help get the message across more easily. But no doubt that's semantics and my own personal preferences talking...generally, I don't criticize whatever works for a given organization...
Thanks for interesting comments and elaborations!
- Linda
Post a Comment