Fog Creek Software
Discussion Board




"Quality Assurance"


Say your organization is a middle-size IS Shop (100 people or so - not shrinkwrap software but supporting company X) and has no formal testing organization.  (Developers test and work with customers on acceptance tests)

If you wanted to create a QA organization or a QA Manager position ... what would that mean?  What would that look like?

A) Professional Testers?
B) "Review" of everything?  (Requirements Review, Project Plan Review, etc.)
C) Spine of development? ("I'm sorry, I can't let joe promise that ship date.  It would create too much risk.")
D) Process Nazi?
E) Process improvement guy? 
F) Six Sigma/CMM person?


Who would you look to hire?  What would his background be?

If we reject the assertion that QA is just a tester-guy, then we can reword "Quality Assurance" as "Software Excellence-Maker" ?

If _thats_ true, how is that role different than traditional management?  Do we have a separation of authority and responsibility?

Thoughts?

quasi-anon
Monday, June 07, 2004

The last place I worked at had (simplied version):

- VP engineering: responsible for all software development, makes promises to customers
- Project manager: acts as secretary to the VP, manages the Gannt charts etc.
- Development team leaders: report to the PM/VP
- QA team leader: also reports to the PM/VP

The VP would ask the development team leaders "when will project be ready for QA?", and ask the QA team leader "when will the project be finished in QA?"

Development and QA "should" work together. It's then up to the VP/PM to arbitrate between development and QA.

Christopher Wells
Monday, June 07, 2004

Within that organization:

A) Professional Testers: report to the QA team leader
B) "Review" of everything: development team lead, and PM; marketing, via the VP (for requirements); possibly QA too (if QA are being assigned early to a project, as opposed to being brought in only at the end)
C) Spine of development: VP
D) Process Nazi: PM
E) Process improvement guy: everyone

Christopher Wells
Monday, June 07, 2004

Consider that QA and Testing are not the same thing. QA means you have a written process and you can show documentation that you follow it. It doesn't mean you have testing, although i've yet to see a QA process without some form of testing.

If you want to improve your testing, adding a QA layer might help, but it might not.

Miles Archer
Monday, June 07, 2004

Bah.

Quality is the job of everyone on the team. Forget having a "Quality Assurance" team and instead hire some evil, cold blooded professional testers to find bugs in your product, preferably the kind that make you weep when you see them in the doorway of your office with a smile on their face.

Fixing the bugs found by a hard-core, professional test team will do more for your product quality than any "QA" process, with all the red tape, documentation and so forth that goes with it.

That's not to say that good testing doesn't have some rigor and is not methodical, but focusing on _testing_ is different (and better) than focusing on "QA."

Mike Treit
Monday, June 07, 2004

> Quality is the job of everyone on the team.

Yes.

> Fixing the bugs found by a hard-core, professional test team will do more for your product quality than any "QA" process, with all the red tape, documentation and so forth that goes with it.

That depends: if the developers don't have good requirements, for example, then no amount of testing at the end will improve the product.

They say that testing, by itself, doesn't add quality: it only proves the presence (or absence) of quality.

Christopher Wells
Monday, June 07, 2004

Mike, thats pretty much what i meant.

Miles Archer
Monday, June 07, 2004

"Forget having a "Quality Assurance" team and instead hire some evil, cold blooded professional testers to find bugs in your product, preferably the kind that make you weep..."

Good testers read the requirements spec and write their test plan while the programmers write the code. In the end they both have to agree on what the requirements really are and whether the code implements them.

Testers who just bang on the keyboard trying to break things are a waste of time and money. Yes, finding bugs is important, but meeting requirements is a requirement.

Tom H
Monday, June 07, 2004

I don't think I disagree, but if those testers find lots of bugs I would not consider it a waste of time or money. You would?

Mike Treit
Monday, June 07, 2004

Uh, hire a Quality Manager and let him build the department as he sees fit.


Tuesday, June 08, 2004

"Uh, hire a Quality Manager and let him build the department as he sees fit."

---> Uh, No.  If we do that, we're at the mercy of who we hire.  And, in my experience, there are a whole lot more charlatans in QA than in other disciplines.

As Brett Pettichord has said "It seems to me that many people who don't/can't understand the technology go into QA where they can focus on process and platititudes ..."

Letting someone else build the department means supplanting our vision and goals for this other guy ... a quick survey of resumes shows that that is not the best idea ...

quasi-anon
Tuesday, June 08, 2004

TomH - in a perfect world developers write good solid code and unit test it to death.  You end up with something that meets an acceptable quality level for the client.  In that case there is no need for QA people.

But since this is not a perfect world, over the past 8 years various companies have hired me to come in and help them make sense out of some real spaghetti code and requirements to mold it into something that they can release.  You only need to talk to the engineers for 5 minutes to realize they know how to do the process right to make it much less effort for testing.  They just don't take the time to do it.

Ricco
Tuesday, June 08, 2004

Going from no QA or Testing to hiring a CMM/Six Sigma person is a big leap and your certain to be depressed when that person tells you everything you do is unacceptable.  I manage a QA team and have grown it from four "testers" to nine Quality Assurance Analysts within a year. With each additional hire I look to bring a skill background to the team which we don't already have.  I've hired experienced testers, an analyst, a technical masters student (developer in QA) and recently a Dr. with a PHD in Astral Physics (he also has more years in QA than I've been employed I think).  I now have a strong team of testers and analysts to meet my customers needs.  My suggestion would be to hire an experienced QA / Tester to map out a master plan.  Test maturity is not only about 'testers' but the entire development life cycle process.  There is a methodology out there called 'Test Process Improvement' which you can apply to your organization and determine your level of test maturity.  The tool or methodology, then tells you which steps to take first to develop a mature test process.  You can significantly improve the quality of your software without hiring a single tester if you put your mind to it.

JKeys
Wednesday, June 09, 2004

Developers (like everyone else) do what they are rewarded for.

If they are rewarded for writing unit tests and producing clear code with documentation to match, they will do it. This reward primarily consists of attention by management. Without that, stating code coverage goals or other numerical standards is as useless as L.o.C. or anything else.

"If you want it bad, you will get it bad."

Richard C Haven
Thursday, June 10, 2004

*  Recent Topics

*  Fog Creek Home