QA Hates You

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…)