Q: What do you do with a tester that feels his responsibility begins and ends with reporting a fault? Refusing to be involved in the resolution, only in the discovery and reporting.
A: Sack their sorry-ass and hire yourself someone who knows what their job really is.
5 comments:
A tester is responsible for reporting a fault and WHY it is a fault. In theory - that lovely, lovely ideal - the requirements that exist should be clear enough to allow a developer to resolve the issue with no further interaction with the tester. Then, when a fix has been delivered, any other person - again, in theory - should be able to match the delivery against the requirements.
Of course, I'd sack them too. Just sayin'.
Agreed! Testers and developers can often stand to review their own job descriptions.
Damian - I think you missed a bit here. Don't just say, "it's broken" and leave it at that. How about some description!?
I have never had any problem with your descriptions - you are always clear about why something displeases you.
Actually, my complaint is more about a tester who will only say, "It's broken". It may be broken, it may not be broken. It isn't possible to figure that out if the tester refuses to be involved in tracking down and resolving the problem.
The tester is not an island. They are part of a team that is attempting to produce a product to an acceptable level of quality. We expect involvement from our customers in fault resolution, I expect more from our own staff. I'm unimpressed when I don't see it.
The best testers I've worked have seen it as their job to provide information on the quality of the release. When a fault is determined important enough to fix, they provide assistance in acting as the local expert on reproduction of the fault.
What you don't see is someone sitting in the corner saying, "It's broken. I'm not signing off on the release until you fix it. Oh, and I'm not telling you how/where I was testing it, let alone why I think it's broken."
Your last paragraph, JP, points towards someone who should be fired immediately, if not sooner.
TC - I thought I'd covered that with saying you need to report why something is a fault. But yes, metadata about the situation is also important.
Finally, I'll just throw my final spanner in and say that testers aren't responsible for raising bugs - they're responsible for quantifying risk. The two may or may not co-incide.
I was just told that the tester just isn't going to come downstairs. However, he did send a developer down to pass on that bit of information.
That's amazing.
Post a Comment