QA Hates You

This article in the Wall Street Journal is spot on: Where Process-Improvement Projects Go Wrong:

What do weight-loss plans and process-improvement programs such as Six Sigma and “lean manufacturing” have in common?

They typically start off well, generating excitement and great progress, but all too often fail to have a lasting impact as participants gradually lose motivation and fall back into old habits.

I’ve sat through enough process meetings to know it’s true. We’d sit in a conference room, chart out a nice flowchart eventually of an ideal situation, and then when the meeting broke up and actual projects started, everyone would do what they always did in the first place. Which is ignore the process.

When you’re trying to improve the process in an organization, you have to take into account the specific organization and the major players within the organization. An outside consultant beaming down solutions from planet Six Sigma is not going to know enough about the industry and about the people within the company. They will offer procrustean solutions that the teams will easily ignore or forget.

The best process improvement can come from within if you have a long enough relationship with other people in the organization to know their strengths and their weaknesses. To improve the process, you need to account for the people who will try to make it work and to accommodate them. You’ll want to capture the best of the things they do and you’ll want to make sure the process handles all of their weaknesses and shortcuts, too, so when the fit hits the shan, the process handles that, too.

A process under glass, framed on the wall, isn’t the goal. Doing things the right way is.

The following is a simulated process for designing anything in the interactive world:

The only difference is that, in a real interactive project, the words would not have been spelled correctly, and sometimes, for no known reason, the design team would use an old, discarded version as the base upon which to make the latest client revisions.

(Link courtesy an interactive project manager in New York.)

If you’re a grade A QA professional, you’ve managed to worm quality assurance into the entirety of your organization’s software development lifecycle (if you’re grade A+, you’ve actually broken out of the SDLC and have someone from the quality team proofreading corporate communications, werd). That means you get a seat at the table in the requirements gathering process along with some free-talking technical guy who’s really a sales guy with a cert or two, a business analyst if you’re lucky, and a customer relationship management yippy dog who jumps up and down agreeing with whatever the customer says and sometimes with something your company’s representatives say. However you got yourself into this predicament, best practice or not, you have to take care of QA in this meeting, and here’s what I do in that situation, particularly if I find myself in that situation disarmed.

(more…)

This post at Worse Than Failure illustrates, in handy chart format, myriad ways that a development project can fail. However, as the post was written by developers, the number of possible ways for complete and utter disaster are probably underrepresented.

Well, you’ve found an issue, ungentle tester; now what? Well, we’ll assume you have some sort of mechanism in place to track that issue, but the software mechanism (usually called a defect tracker, but sometimes known as the developer’s junk e-mail box) only serves to provide a technological means to support a process that handles these issues. That is, your organization needs to have an effective idea of what to do when QA starts identifying what the developers have done wrong and how to make sure that the issues are addressed correctly. That is, the developers are brow-beaten into actually opening up their little script editors/Eclipse/IDEs and making things right.

This post, then, will discuss various ineffective defect processes I’ve seen and how issue resolution should work. (more…)