jump to navigation

Confusing Test Terms – And Does it Matter? November 12, 2009

Posted by yvettefrancino in QA.
trackback

There are several terms in the world of QA that many people use interchangeably. Each one of these groupings is probably worthy of its own blog post.  I’m not going to define them now, but if you’d like to jump in with a comment and your favorite set of definitions for these, feel free:

Severity vs. Priority

Verification vs. Validation

Test vs QA vs QC

Load Test vs. Performance Test vs. Stress Test

Bug vs. Defect

When I was a kid, my friends and family used to tease me about being irritatingly precise about everything. If they used a word incorrectly I would tell them that wasn’t “exactly” the right meaning.  If they made some kind of assertion as though it were always true, I’d find an exception. My father told me I should be a lawyer because I could find a way to dispute just about anything.  QA is another good career-choice for people  that love to find things that are wrong, even when it really doesn’t matter.

As I’ve grown up, I’ve mellowed out a bit– or maybe I just find myself making the mistakes and now other people correct me. I think…  Ah ha! That’s what I used to sound like! No wonder I was never invited to be part of the “cool” crowd!

Originally I’d thought about defining the terms above by pointing to their “official” definition, but as I roamed around the Web trying to get the “official” definitions I realized that there is not even total agreement on that.  And even if YOU know the official definition, it doesn’t mean that the tool you are using or the person you’re talking to will necessarily be using these terms in the “official” way.  What you need to do is find out who you’re talking to and agree on how you’re using the terms and use them consistently. Or, if you’re using a tool, you need to understand how that tool defines these terms.  If reporting will be done on the data, it should be really clear to everyone that needs to input the data exactly what it means. If half the people are using one definition and the other half are using a different definition, the data will be misleading and possibly meaningless.

For example, let’s say you worked in a company where everyone used the term apple instead of orange. If you were a new person in this company, the first time someone said, “Hey, would you like an apple?” and they gave you an orange, you may be tempted to say, “You are mistaken. This is an orange.” And they would say, “We call these apples. Do you want one or not?”  You could then  try and educate the company on the differences between apples and oranges, insisting they were using the terms incorrectly (possibly resulting in people using you as target practice when they feel like throwing an apple or orange.)  Another approach might be to just call either one a piece of fruit.  Most of the time it wouldn’t matter. You’d come to know that oranges are always called apples in that company.  But if the company puts a tool in place that would ask you for the number of apples you ate each day you might be really confused about whether to put in apples or oranges.  (Or you could just be like me, skip the fruit and eat candy.)

My point here is that what matters most is that the term is being used consistently organizationally amongst the people that “care”, especially if metrics are being gathered. (I will note here that a whole lot of people don’t “care”  — and thus, may take issue with being corrected.)  But if metrics are being gathered and reported on, it’s best to have a very clear definition of how the term is being used in that specific context.

I note this because my next blog post is going to be about a defect prioritization scheme in which the terms Severity and Priority are used differently than I’ve seen in the past…  Stay tuned!

Advertisements

Comments»

1. Dave Whalen - November 13, 2009

You know my favorite! :o)

2. Parimala Shankaraiah - November 13, 2009

I have worked in organizations where same type of testing is referred to using different jargons. As long as that is the correct way of doing it, I would not mind calling it by any name.

Happy Testing,
Parimala Shankaraiah

3. Jim Hazen - November 13, 2009

Yvette,

You forgot one: Testing vs. Checking
As James Bach and Michael Bolton (and not the signer) would argue over.

I look at some of this and just think we are our own worst enemy. No wonder the other groups in software think we are a bunch of nuts.

Jim

Dave - November 13, 2009

Well if James and Michael said it, it must be true…NOT!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: