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.