To Think or Not to Think… That Shouldn’t be a Question… Ever

So many times, a QA is afraid to ask questions, or take the leap to upset people.  Both of those actions are our Job!

I hear all the time from various QA professionals “but the requirements don’t say that, so I guess it is ok”.  Really?  The question hit your mind, and you think it won’t hit other people’s minds?  Are you a “Tester” or a “Quality Professional”?

As our world starts to adopt more Agile methods of software development  QA is becoming more important.  Yes, Quality is the responsibility of more than just the QA resource, it comes down to the BAs, PMs, PGMs, PDMs and Developers… Everyone in the project is responsible for quality, however, we as Quality Professionals (Unless you have decided to be a button monkey) many times have insights, or thoughts that can stop major issues that affect the “Quality” of an application we are responsible for testing.  Just saying that it is the BAs role, or the PDMs role to make sure that there isn’t a conflict with requirements vs. some established business rule or other application is insane.  Not that the BA or PDM didn’t do their job correctly, they most likely did, but they are human.  As QA we are closer to the end user and also close to the technology.  We have a unique perspective and can at times provide data to these other principals that they didn’t think of (I do it weekly).  That only elevates the view of QA.  Let’s face it, we are still the ones that people don’t understand or want to pay for.  We are still second class IT peeps.  The more we can add value, the more we justify our profession.

There are many different agile approaches, so I will reference only one that I am currently involved with because I think the same concept of “thinking” applies for any paradigm. This comes from experience, and I am only going to approach it from a philosophical high level that puts it out there.  Refer to the tagline of the blog… you get to have your opinion even though it is wrong.

Let’s look at Iterative/RUP/MSF approach:

High Level SDLCish Description

O.K… This is a high level approach and outline of what happens.  It is from a consultative view because I am a consultant, however shouldn’t we all be even if we are in-house?  Don’t we have “clients” when we are in-house?  Don’t gripe that this doesn’t match “SDLC” definitions, this is conceptual view of how things happen.

1. Prospect is approached for a solution
2. A need is identified
3. They promise to give us $$ and we promise to provide their dreams
4. Design begins for a solution
5. We realize the Dream needs to reside in a Pipe
6. We design a new dream to fit in the pipe
7. We take sections of the pipe in pieces and stuff little bits of the dream into the little bits of the pipe
8. QA makes sure that the pieces of dream are where they need to be
9. We show the client that the pieces fit
10. Repeat 7 and 8
11. We give the client their solution
12. Everyone is happy (we hope)
13. Client sends us on new Mission

So, now lets look at where QA is usually involved.  Pretty obvious.  Item 8.  That is about it.  I am not able to buy in that “Item 8” is the only place for QA to be involved.  I believe that we can really put value in almost every stage, even if only passively. 

I may get into specific approaches in a later post (or not) but to get your QA gears turning to how you can promote and add value, here are a few major places we can make a difference.  I believe we can make influence and add value in more than ust these.  The following items are tied to the above list:

4) When we are involved in the design.  We have Value.

1. If the system is already existing, we should have been trained in domain and application.  We can see conflicts from end user standpoint.
2. Even end users don’t think things through all the time.  If we accept things at this point with no thought, then we have failed to provide quality.

6) It may fit in the pipe from a technical standpoint but….

1. The Call center can now add a record that they can’t retrieve for 30min
2. What we put in the pipe doesn’t fit in the other guys pipe

7) Same as 6 except that that may be ok if this isn’t going to production until full development is done.  Iterative is the keyword on this point.

8 & 9) These are given … button monkey…

10) Is it You?  Is it PDM?  PJM?  we should review and make sure they are not misrepresenting.

11) Does the install work?  Does the Deploy work?  Have the people deploying taken necessary rollback contingencies?  Is it documented?

What I am trying to say is that we should question everything.  Don’t be afraid to stand up.  Even when you get pushback, be nice about it but let your views be known.  You to can get emails that say “Thank you for keeping us honest” or “Thank you for saving our …” even from the people that pushed back. The key is to know when to let go. (yet another post I should do, but how do you put that into points?)

It may be that it is coincidence that “QA” means Quality Assurance and also means Question and Answer… It may also be something more deep.  Question everything.

I haven’t posted in a while

Just a status as to why this blog was a slow starter:

[Insert Son’s Name Here] Was Born on June 30th in Surigao City Philippines to Kenneth Hastings and [Insert Wife’s Name Here]. 

 

My focus has been a little …. sideswiped.

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.