I've heard the term "QA Analyst" bandied out a bit lately. My initial thought is that we are in dangerous territory - "pure" QA people are responsible for quality but aren't the ones actually doing the creation. Let's think about this for a moment:
When people think of QA, they usually think one of two roles:
1) Super-Tester-Man. This job is routine and boring - running the same test cases over and over again on software.
2)Process Nazi. "You can't write any code until you get document 2A, B, and C filled in and signed by all stake-holders!"
Both of these are jobs-by-rote, unthinking jobs. Good people quit such jobs - and bad ones won't add value, by definition.
What's worse, typically QA guy has less business experience than management and far less technical skills than the software developers. Even if he finds an area to improve, why should anyone listen to him?
If we're going to do QA in Allison's Resturant, then the person who is doing the QA -has- to be a cook. (Person who knows how to create the product)
In fact, I would argue that it has to be a relatively senior cook - who also has spent some time studying the business. Because, after all, what is Quality Assurance?
The QA person would have to notice that the hostess is promising a 10 minute wait for a table when it's really 20, and would have to know when the waitress fails to prompt a customer for salad dressing and just guesses "ranch." Also, he would have to know when the cooks, under pressure, are turning up the heat just a bit too far to get things done quick - and taking things out just a tad bit too early.
And he would have to know how to fix it - and which problem offers the best improvement benifit for the least cost.
As I see it, then, the QA role is something that a senior software developer looks up to being - it's the next step in a technical promotion track - and it's where the technical track splits from the management track.
Without this level of credibility, the QA person will go to meetings and be ignored, shuffled around, or (possibly) blamed. If the QA person is to be responsible for problems, he must be able to actually fix them - and only a senior developer with learned business experience will be able to jump in, write code, write tests, improve project plans, etc, etc. That this gives people with 10+ years experience something to aspire to is good as well ... it's kind of sad when people climb the entire technical ladder in 3 or 4 years and have no where to go.
That completes my rant. I'm thinking of improving it a great deal and turing it into a 5-minute talk for something like Gr.PM. What do you think?
Postscript: This is not to say that the Sr. Developer should take on a rote-job; just the opposite. The challenge is actually assure quality by thinking, as opposed to doing anything by rote.
Instead, the QA guy would walk the entire lifecycle and think, saying things like: "look, this project plan is incomplete. All the estimates for phase IV are based on the due date - they have no basis in reality. We need to do our due diligence here, or else we are just lying to ourselves ...
That is the way to actually Assure Quality. And to do that, he needs to be a cook.
Re:You're looking from the wrong side
heusserm on 2003-08-21T19:05:10
And programmers should never work primary QA for programs they wrote--they're useless in that case, often times making things even worse
I completely agree, and I wasn't trying to imply that should be the case.
After I get some feedback, I'm thinking of posting a bit more in the next couplea days, to "flesh out" my QA worldview - but, basically, the programmer who is elevated to QA levels is elevated because he is the exception - he didn't "make excuses for deficiencies in the product or nearly instinctively work around problems" as a coder, and that earned him a promotion.
The idea, then, is to make his mentality infectious.
Or something like that.
