QA Hates You

You know what’s worse than your development team? Someone else’s development team. At least, your development team has to deal with you. Whether you have the dev team frightened of you, fearing for their existential meaning and worth because you can hold them accountable, or you have the dev team ignoring you until such time as you can triumphantly claim, “I told you so!” when something fails spectacularly, many shops don’t even have that. And they’re proud of it. Chances are, if you have to work with some other group for any aspect of technology or design, it’s going to be crap. Because that QAless organization has a better grasp on the whole “It’s more profitable if we do it with eyes closed” and “Deliver the client’s minimum expectations at maximum bill rate” things than your organization, which is why you’re employed and why your company is at the mercy of slops.

So when you’re working with a third party product or service, you must demand that that product/software meet your level of quality. Get it in writing, because otherwise they’re going to cheap out on you, and you know who your client is going to blame? You. A lot of organizations, even some with QA staffs, feel that as long as they can prove that someone else is to blame for the failure (that is, the third party vendor or solution), they don’t have to worry. Even if the client has told you to integrate with crap, they’ll expect the end result to be a rose garden, not deeper manure.

That being said, here are three ways your “integration” might fail based on what you’re integrating.

1. Integrating an off-the-shelf product.

Sometimes, an off-the-shelf product offers some functionality that your organization needs. Why reinvent the wheel? A couple of API calls and a couple of hacks, and WALLAH! You’ve got some polished piece of functionality prebuilt to bundle into your project.

The integration point between the two pieces of software is a tenuous link at best. If it’s commercial software, the application probably has some internal validation controls to prevent users from doing bad, bad things within it. However, those API calls or whatnot are probably very, very trusting. And if your developers insist upon integrating some sort of open source software into it–well, God bless you, Howard; you’re on your way into Hell.

For example, I once worked on a chemical modeling piece of software that used a third party sketching component when the user wanted to draw a model. When the user wanted to draw a molecule, the application popped open this chemical sketcher so the user could draw bonds and chains and whatnot. Of course, I am not a chemist and don’t play one on television, but I did learn enough about this third party component to get an idea of how it worked. When the user closed the sketcher or selected Transfer to Application Under Test from the File menu, the sketcher passed the molecule back to the application our developers were developing.

Now, that commercial piece of software offered some hints and visual cues, such as special highlighting when you tried to create the seventh valence bond on a Carbon atom. Why, that flies in the face of all natural law. But pass it back to the application under test, and HAVOC! Or create a molecule that’s a mile wide by a mile tall and pass it back to the application under test, and HAVOC!

Because the application under test was accepting, uncritically, data from the third party software that the third party software knew was flawed or that wasn’t flawed, just really, really big (sort of like the Hamlet test with atoms). The developers, lazy souls that they were, trusted their counterparts at the commercial software company to do their validation work for them. At a cost of many, many defects with my name in the submitter field.

2. Integrating with other service vendors.

Sharing data and functions with other vendors is fraught with danger. Apparently, only 37% of companies using SOA are receiving positive ROI. And of that 37%, 100% of the survey respondents know their bosses review their survey responses (as estimated by QAHatesYou.com). Want to know why?

Because integrating with other companies’ development efforts squares or cubes the worst parts of the development lifecycle. While the ultimate clients’ needs shift, those clients incompletely convey those changing requirements to you and your integration partner, and your integration partner won’t convey the changes they made to the Web services or COM interfaces or whatever neat new technological mechanism erupts in the next couple years. They probably won’t test them, either, or allow you direct access to their databases or build in any sorts of data validation mechanisms you can use to make sure your company’s calls to their software work. Which would be helpful, since they probably lack a QA staff and the calls won’t.

Sure, sure, I realize that your company’s projects will all have proper documentation, excellent communication, and conference calls that are not two minutes of greetings and eighty-eight minutes of recriminations, accusations, and denials. I also realize that you’re telling me the same thing you tell your client.

3. Using an outside company for small projects.

When you’ve got a tolerable Web site up and running and you outsource small portions of it–such as forms processing–to outside vendors, you can get poor results. For example, the St. Louis Post-Dispatch recently outsourced some contest form processing to an outside vendor.

Here’s the banner ad and the header for the newspaper’s Web site:

Click for full sizeClick the banner ad, and you’ll go to the contest form (soon to be dead, no doubt.

Well, I’ll start out with quibbling about the mismatched copy and control here:

Click for full sizeThe copy says to click the box, but the designers have added a radio button control instead of a checkbox. That’s senseless, but no doubt it was quick and senseless.

Unfortunately, the real problem lies with the thank you page that displays after the user completes the form. As often happens, the third party vendor tries to recreate the look and feel of the client site, often to disasterous results. Here’s what this particular thank you page yields, with an incomplete banner and missing images on the mouseover:

Click for full sizeIt’s a quick one off, but ultimately this poor design and the missing images reflect poorly on the St. Louis Post-Dispatch‘s Web site, not the form processing third party. But they must have hit the minimum the Post-Dispatch would accept with the tight deadlines that sweepstakes and contests mandate.

So what’s my point?

I’ll sum it up, briefly, for the developers who might read this and be confused about my point. My mates in QA: be warned that other companies’ developers are less trustworthy than yours. If your project is going to use someone else, you better make sure to show them the billy club early and often to make sure that your integrators do the work up to your standards and that your developers make the integration airtight.

This entry was posted on Monday, August 20th, 2007 at 12:15 pm by The Director and is filed under Failed applications, Failed Web sites. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.