Quality Assurance Code of Conduct

Question

I haven't been able to find any good resources about QA code of conduct and would like to start documenting this. The main issue I have is really basic stuff like:

• Someone reports "the design is broken" when the real issue is they are using IE6 and haven't updated their cache.
• A team member says you broke the build, when actually they haven't retrieved the latest revision from source control.
• Someone complains their data is being lost when they navigate to a certain page, without explaining how they got there.

I'd really like a document I can hand out to clients or team members the next time they complain that "this code sucks" when in reality what they should be saying is "this code does not accomplish our business objectives".

Answer 1

This sounds more like an interpersonal problem, rather than a technical one (except maybe the last point).

If you feel people are not polite and respectful to each other, there are many solutions (consulting, coaching etc.), but that should be considered and treated as a social problem, not a technical one.

If it is a simple error on part of the complainer, some kind of internal training might help. Unfortunately I do not know any good code of conduct for that.

There are some guidelines for reporting bugs, e.g.:

https://developer.mozilla.org/en/Bug_writing_guidelines

http://catb.org/esr/faqs/smart-questions.html

These might be a starting point. But much will be specific to your environment, software etc., so it's unlikely you'll find somehting that's ready to use.

Answer 2

Spend a few minutes to talk to someone in person if possible and otherwise on the phone.

Only using email of bug tracking systems can really lead to these kinds of situations where both parties feel frustrated about the issue.

You need to get from communication at the level of

'this thing sucks'

to

'I get really confused when I do this and that and then this happens etc.'

You need to understand why and where people see problems and what minor issues may be causing enormous frustration for your testers and/or customers.

You may also need to help them understand why things are the way they are.

And that you may know that there are problems but that it can not be fixed right now because it would be risky or more important issues have priority.

Answer 3

I'm confused - when you say I'd really like a document I can hand out to clients or team members the next time they complain that "this code sucks" when in reality what they should be saying is "this code does not accomplish our business objectives".
What's the difference? terminology? code sucks or does not accomplish or even worse not using it or paying you for it and losing clients leads one to think that instead of worrying about how they say it the focus should be how to actually get the code/application to where it should be to get a more positive response. Be happy that they're giving feedback and just not ignoring you/you're company. Get all the negative feedback you can, objectively look at the application itself and determine what steps are needed to get it in shape.

Answer 4

An ancient Joel article might help: Painless Bug Tracking, whence:

It's pretty easy to remember the rule for a good bug report. Every good bug report needs exactly three things.

1. Steps to reproduce,
2. What you expected to see, and
3. What you saw instead.

Seems easy, right? Maybe not. As a programmer, people regularly assign me bugs where they left out one piece or another.

Answer 5

While it's true that bug reports like "this doesn't work" aren't very helpful, you have to realise that not everyone is a programmer.

Most people who "complain" simply don't know what information they CAN provide to be more helpful and assume you know what they're talking about. They also often aren't aware of their "tone" because they're not always as used to precise written communication (even manager types can be blatantly ignorant of this -- programmers OTOH tend to be total fanatics because they're used to having tightly packed semantics in a short block of text because that's what they do for a living).

You need to explain what you need to know in order to understand a bug (i.e. be able to reproduce it or track it down). Guidelines like Mozilla's help a lot if they're present in the bug tracking system. If your bug tracking system mostly consists of QA sending you angry letters, you'd probably fare better by actually talking to them in person and explaining to them how they can be more helpful, provided they care.

If they don't care, you're screwed anyway.

Answer 6

Some good answers here. We know what we need in a good bug tracking database. Those same features, properly exercised, work towards educating the bug reporter.

This is where good bug database moderation comes in. Bugs should immediately be qualified and categorized. All missing data should be put back in the user's court, and when not provided, the bug put on hold. No data for a month, it's not important to the user, the bug report is closed.

When customers see their bug quickly demoted in priority ("affects only one customer occasionally"), marginalized ("cannot reproduce", "not enough data provided to identify"), sidelined ("waiting for missing information","recategorized"), etc., they'll pretty soon realize they have to step up to the plate and play ball. Provide more and correct information or it goes to the bottom of the pile, and then goes away altogether with the next minor release.

Petty, snarky comments of the user are encoded in the bug database forever. Polite responses, or better yet, automated ones are the only thing from the developer's side. Every new input of data is addressed by a human with a Thank You and a change in bug status.

Sure, they'll complain about the threshold of effort required to properly report a bug. They'll complain about the prioritization. They'll complain about the bugs being closed out after a timeout or at the next software release. You just shrug and say, if it was so important, they'd work with you and give you what you need.

If they want revenge, they can hold the bug open by continually reproducing the problem and inputing more data about it. Then, you'll have what you need to fix the bug.