Monday, May 3, 2010

Defining Definitions

I was recently inspired by a blog entry (that I am sure to reference) to think harder on something that I have believed for a long time.  Terminology Matters.

I haven’t changed my view much on this concept; more or maybe less “defined” would be a better description.  After all, it is hard to change the stubborn mind of this American: just ask my team members, although it is possible.

How you say things, and what words you use can, the operative word being can, affect your ability to effectively communicate.  Most issues on a software development project can be tied to lack of effective communication when you assume that your team’s skills are up to snuff.

I will start by providing some links.  I think the dictionary is a good place to start in making my point or lack there of since the lack of point…. is the point. 

http://www.merriam-webster.com/dictionary/definition

http://dictionary.reference.com/browse/definition

Given that my English teachers throughout my education always said that we “should never define a term using the term itself or any variation of the term”, even the dictionary has a problem with the word “definition”. 

I will say right now, in your situation I am probably wrong but I am absolutely right.

Does it Matter?

Yes and No?  I will put forth a conversation I have had with a specific term that outlines just how nebulous we are.  Even though terminology doesn’t matter as long as everyone knows the “general definition” accepted by a team, if it hasn’t been hammered out it can cause confusion:

Tester So Andsew:  Can you look over my test plan?  I just started and my contact at the client asked me to start writing the test plan.

Me: Sure, just send it to me in email or the link on the shared drive.

Tester So Andsew: It isn’t a document.  I started writing the test scenarios.

Me: That is great that you have started writing scenarios, but I thought we were talking about the test plan.

Tester So Andsew: Right.  So it isn’t a document.

Me: Huh?  Who is on first?

A little background on this is that, at least in my world, a test plan is a document.  It describes the plan for testing the current software iteration based on a test strategy (a guiding philosophy document for the release… I will blog on THAT thing later… Test Plan vs. Strategy vs. some Frankenstein amalgamation that is not very useful beyond an exorcize of busy work)

I finally figured out that he was referring to a “test plan” as the information he was placing in a specific tool under the “test plan” icon down the left.  Basically… he was writing test cases.  “Test Plan” is where the tool stores these.

This is an example of where terminology matters and doesn’t at the same time.  Had I been privy to the terminology his group was using… It would have saved me the time trying to figure out the situation.  Yet at the same time, had they been using a standard of the test plan being a document… It would have saved me time because the question would have been “Can you look over my test cases?”

I think that there are certain terms that should be more definite and defined within our industry yet are still ambiguous.

White Cobra Testing

Ok.  I am alluding to a blog post that inspired this blog post.  There are also terms that don’t really matter (a.k.a. buzz words).  They either get legs and a life or they die out.  For those of you who don’t realize that I put a hyperlink on those words… (I know you are out there and also a QA person) here is the link:

http://testertested.blogspot.com/2010/01/black-viper-testing-technique.html

Many terms are bounced around the forums trying to figure out what something means.  I agree completely with Pradeep that the majority of these terms are things that come up in interviews.  I am probably one of the culprits when it comes to things like “Smoke vs. Regression testing” or “Client/Server vs. N-Tiered Enteprise Stack”.  However I wouldn’t ask the difference between “Smoke and Sanity” testing.  Who cares.  They are probably the same thing.  I know in my world I use them interchangeably though I like the term smoke better.  It sounds more mystical and important than sanity testing.  Makes me sound cooler. Isn’t that after all the point of using buzz words?  To sound important and “cool”?

Summation vs. Summary

So… To wrap it all up.  I don’t know how to tell you where or in what way to decide the definition of a term in the QA industry or any other industry for that matter.  Sometimes, it doesn’t matter.  I can have apple testing if I want to on my project.  Just everyone needs to know what it means within the context of the project.  Agreement is needed.

At the same time on the larger, worldwide industrial consulting realm there are some terms that should be somewhat standardized so that when talking to a new client, or on boarding a new resource there is little effect from a miss-alignment of terminology.  Not to mention the big world of interviewing.  How do you litmus test a new resource when you are looking for experience.  There have to be some things that are sacred.

Again… in your situation I am probably wrong but I am absolutely right.