Quality Assurance people are important and valuable, to be sure, but they can also make developers’ lives much more difficult. This is particularly bad because (like many roles in an organization), their end goal is to help the developers make better software, not stress them out.

Here are some of the common ways QA workers ruin developer’s lives and how these behaviors can be avoided:

1. Misunderstanding the technology

   I’m often shocked by what somebody on the team didn’t know about. Understanding when software is working properly and when it isn’t can sometimes require a deep understanding of the technologies involved in making the software… And sometimes you just need to know enough.

   My favorite example of this is a bug I got about a year ago, in which the report was something along the lines of, “Page is dumping out plain markup, no CSS.” Sounds kind of like an RSS feed right? It was. This person had never heard of RSS.

   How to avoid this

   I hate to say it, but sometimes people just need to be qualified for their jobs. A unique perspective on a product is sometimes great, even sought after (for example, during usability tests). Other times, people need to do research and read up on the projects they’re working on. Most projects have awful documentation, but if they have it at all, it will probably mention in there what something like RSS is.

   On the other hand, nobody can know everything about everything. Technology moves quickly (especially when dealing with the Internet), so it’s understandable to be behind in a given area. A better way to handle this issue might be to suggest that perhaps the page could provide more information about what was misunderstood so that if others come across the same page, they’d understand too.

2. Assuming the software is buggy

   A friend told me about a bug he received recently. A QA person had tried three different features in the software that were supposed to display images. None of them worked, so three different bugs were filed. Thing is… those three areas of the software worked fine. It was the image that was broken. This person just assumed the software was buggy.

   How to avoid this

   When something is not behaving as expected, all reasonable checks should be made before branching out and getting others involved. Sometimes it’s as low-level as checking the Internet connection, and other times (as in the example above), it’s seeing if something works in other software. Pulling the image up in a browser or editor would have shown that the image was broken. Instead, everyone’s time was wasted.

3. Omitting necessary information

   I very recently received this email:

   Hi Matt there is Javascript errors on Devtool editor and preview pages. Do you want me to file a bug for them in one bug or are you already fixing (have fixed ) them?

   This email was next to useless. First off, I don’t know what environment these errors were found in. Typically at work we’ve got a handful of environments, sometimes up to five or six, and almost always I don’t know when they were last updated. All I know at any given time is about my development box, which I doubt people test on.

   Secondly, what browser and operating system were these errors found on? This is critical in a world where browsers behave so differently.

   Lastly, what were the actual errors and (probably more importantly) how did you produce these errors? Sometimes it’s very obvious. Load up a program or hit a webpage and the same error pops up for everyone on every operating system or every browser. Sometimes. But not usually.

   My all-time least favorite among the “not enough info” issues are the bugs that say something like, “looks funky” or “is broken”. I know what I think is funny. I don’t know what you think is funny. It’s ambiguous. If someone says, “it’s blue but it’s supposed to be red,” then I understand perfectly. Otherwise, there are blanks that need to be filled in, and a failure in communication has occurred.

   How to avoid this

   In short: I’m the developer. Need the info.

   All that really has to be done is to answer each of the questions above. I’d love to know about errors if there are any, but I must have the bare essentials of information about them, and usually the more information the better. Help me help you.

4. Not knowing the specifications

   Long ago, I lost track of how many bugs I’ve closed with a comment along the lines of, “This is by design.” Sure, sometimes nobody knows how the hell something is supposed to work, but if you’re doing it right there is documentation that answers these questions. It’s especially frustrating because the software is behaving exactly as intended and a bug is filed that (unknowingly to the creator) basically is saying, “Everything’s good, but I’m not aware of that.”

   How to avoid this

   Read the documentation. Know how it’s supposed to work. Don’t assume it’s broken. If all else fails, ask before filing a bug.

5. Over-filing bugs

   I’m primarily a front-end guy, so I get a lot of design tweak bugs. Sometimes a character is missing, sometimes a border is too thick, sometimes a font is one point too large… These tiny issues often take mere seconds to fix. What takes longer is managing each of the bugs created for these issues.

   A site I was working on a while back had a list that looked something like this:

   • Upgrade users
   • Truncate users
   • View users
   • Mass edit users
   • Import users

   For each bullet point in this list, I was assigned a bug whose summary was something like, “Add a period to the end of ‘Upgrade users’”. That’s five bugs for five really easy fixes. What a waste of everyone’s time!

   How to avoid this

   Bugs happen. Tickets for these bugs need to be filed. Usually they are unrelated and separate tickets are not just good, but necessary. However, knowing when to create fifteen bugs and when to create just one is very important to know in order to be efficient. Sometimes it’s best to think about the issues at hand and consider if they’re similar enough to be filed together.

   Another cause of over-filed bugs are duplicate bugs. This one’s easy, folks; just search for similar bugs before filing.

Note: I certainly hope this article hasn’t offended any kind QA folk. When they’re good at their job, they make my job way easier. Let’s hear it for QA!

(Special thanks to Isaac Schlueter.)

Array objects and null variables do not return expected results. You can try this out for yourself here:

<br /> // Array<br /> alert(typeof []);</p> <p>// Boolean<br /> alert(typeof true);</p> <p>// Function<br /> alert(typeof function(){});</p> <p>// null<br /> alert(typeof null);</p> <p>// Number<br /> alert(typeof 1);</p> <p>// Object<br /> alert(typeof {});</p> <p>// String<br /> alert(typeof “”);</p> <p>// undefined<br /> alert(typeof undefined);<br />

Array
Boolean
Function
null
Number
Object
String
undefined

This behavior is shared among all of the regular browsers including
Firefox,
Internet Explorer,
Opera and Safari.

[Source: A Survey of the JavaScript Programming Language by Doug Crockford]