QA: The Req’ing Ball

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.

You might be tempted to keep your eyes on the tabletop and hope no one knows you’re there and no one calls on you (no one will, of course, because they don’t know why you’re there and, if you’re doing your job effectively, they don’t like you anyway). You might be tempted to make snarky comments and deploy the normal gallows humor, frightening the client. Well, do so, but sparringly. Mostly, though, you’re there to do two things.

One, you need to shoot for the moon on features. You have to ask the client pretty much if he or she wants the application to wash his dog for him. The more features you throw out, the more chances the client can say, “Yes, I want that,” and work that into the estimate, or the client can say, “No, that doesn’t make sense,” or whatnot. Because the client’s going to take a look at whatever your organization puts together at some milestone after the company has expended pizza budget on getting something mostly working by the milestone, and the client will then say, “You know what else I want it to do?” At that time, the yippy customer service person will agree to anything just to get his or her commission, and the timelines and budget might take a hit, especially if the client said he wanted it to wash his puppy in the first place, but also wanted it to wash his golf balls. A little change directive won’t account for major refactoring, especially since the client will want to have secure login next time so that his business partner can wash his or her dog or bowling balls.

You need to get out ahead of that and try to think of how many features and enhancements and alternative workflows you can think of to get them down on paper before you begin.

Two, you need to make sure that the requirements account not only for happy path use cases, but also that they capture how the application should behave when the user steps off of the happy path. Most of your defects are going to come from this area, particularly if you leave it to the developers to come up with their own ad hoc solutions and assumptions. Face it, you’re in QA. You’re the best one in the room for imagining and creating disasters. Create them here, get them on paper, and then make sure they’re handled according to plan. Otherwise, when you do the black magic you do so well in the testing cycle, the developers will have to send down to the gift shop for more chewing gum to implement their fixes–if they bother to at all.

So there you have it. Swing for the fences in requirements gathering. Sure, it makes more work when the client loves half the ideas, but the client was going to come up with those on his or her own halfway through the project. And then the client will like a couple more of them, and you can point out where he or she said no when they were proposed, and fixing it will add cost to the project.

Sure, some of this is the work of business analysts, but I’ve worked plenty of places where they fell down on the job. So get yourself to A rating and get into those requirement meetings. At best, it will save you and your organization time, effort, and refactoring. At least, you might get lunch and the opportunity to frighten a real live client.

Comments are closed.

wordpress visitors