views:

109

answers:

6

I have a web site I am building for a client. I now have a tester on the project with me.

I feel testers are needed. REALLY! I cannot test my own code. I also appreciate the value of a new set of eyes. But what desires reporting?

It is easy to say everything should be reported, but I don't have someone between me and the tester to filter out the unimportant requests. The tester does not know the system nor the target user well. She is assigning me tasks and not the project manager. I think this will change soon, but until it does, what do you recommend? There seems to be a believe that our users have NEVER used the interent before at all, and they are as dumb as rocks.

The problem I am having is that EVERYTHING the tester suggests is being accepted automattically and assigned to me.

I have many cases that make me drop my jaw and say "Really? Are you serious? This deserves to be a issue?"

Ex: Need to add text at top of page that says "* = Required" for required fields.

Have you ever felt this way? How did you deal with it?

For now, I am just doing as I am told, but I am making it clear I do not agree.

A: 

I would report to the client what each change will cost in terms of time and money. Things that are legitimate bugs you'll probably need to fix on your own time (unless your contract says otherwise). Things that are design / subjective issues you should be able to assign a cost to. Let the client know what it is going to cost them and they can decide if they want to proceed or not.

Hopefully you've got some sort of a project specification that the client has signed off on so that you know when the project is complete and what sort of things are not included in the project scope. If not, you might have a bit of a fight on your hands. For changes that you think are outside of the project scope, you might need to compromise - maybe bill them at a cheaper rate or split the cost with them. If you're in that situation it's a good learning experience to get everything documented in the project specification so that there is no question about what falls outside of the project scope. I've been there - one experience like this is enough to teach you to put more work into your specifications.

TLiebe
It would take longer to estimate them than to just make the change. The real problem is I am so over this project and I just want it finished. Thanks for your answer.
Bobby Ortiz
+2  A: 

You need to add priorities for your issues. This will allow you to do the important issues first, and cosmetic issues last. Here is example priorities from Jira:

  • Priority 1 - a reproducible crash; issue blocking any further testing or development of a specific feature; loss of user's persistent data; huge memory leak
  • Priority 2 - a major issue that must be fixed before the product is released; prevents users from using a feature; negatively affects partner; significant memory leak in frequently used functionality
  • Priority 3 - a minor issue that should be fixed before a product is released; does not prevent users from using a product; highly visible usability issue; small memory leak in rarely used functionality
  • Priority 4 - a purely cosmetic issue; doesn't affect functionality
Ivan Nevostruev
+5  A: 

It sounds to me like your tester is doing the right thing. You can't assume any level of user expertise when testing an application. If a user can break something, they will.

You and your tester need to work out a severity scale. The outliers (those that anybody with Internet experience could probably work around/would never hit) would be considered low priority and sit on the back burner until you knock out the high priority items.

...never the less, those outliers should still be logged because they can definitely come back to bite you in the ass in the end.

Justin Niessner
Thanks. I guess I am being a little bit of a baby. All the high priorities are done, and I just want to move on to another project. It takes me longer to document the fix than it does to make the change.
Bobby Ortiz
Lucky! I wish I had a few more tasks like that.
Nathan
A: 

Report everything and triage. After a bit of time, she'll start to understand what gets past triage and what doesn't. Humans can learn; teach.

jeffamaphone
+1  A: 

Actually it sounds like your tester is doing the right thing (and the text for "* = required" is a very good idea).

In addition to the suggestions about prioritizing reports, I would suggest that you categorize the reports as to whether they refer to user experience or functionality.

Liz Albin
+1  A: 

You and the tester will never exactly agree on what "needs" to be reported. Just set the priority on issues correctly, and get on with fixing the high-priority stuff first.

One thing you absolutely do not want to do is to discourage the tester from filing bugs. That'll come back to bite you when something ships totally broken, and they say "I thought that was just how it worked".

Do make sure that you're communicating the development schedule and status properly, so they don't waste time testing features that aren't sufficiently complete.

Mark Bessey