Comments on PRACTICAL QA: SAD LITTLE MONKEYS…

Joel, you somewhat missed my point; your definitio...

2009-05-04T10:04:00.000-04:00

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

Linda, First of all, it’s nice to see one’s words...

2009-05-02T05:45:00.000-04:00

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

I have the same issues. In fact, developers have ...

2009-05-01T16:09:00.000-04:00

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.

Nice post. I like your general statement. I think...

2009-05-01T15:01:00.000-04:00

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.