I would normally expect management to look through the issues every so often (say, every week), and allocate depending on schedules, severity, forthcoming releases etc. Some questions are:
is it an issue a bug, a feature request etc.?
does it prevent your client from working with your tool ?
is it impacted by forthcoming work (e.g. will a new feature remove the feature causing the issue) ?
I don't believe you can resolve these issues in isolation. It requires project managers etc. with awareness of project direction and programmers with awareness of the codebase to work together to determine how/when issues should be addressed, and their impact on other work streams.
Initially you should have a support department that does triage on all newly added issues. They should be empowered and informed enough to decide whether this is a non-issue, whether there's a work-around or whether they don't know. If it's the latter then it should be elevated to programmers.
You might also want to include the testers in the chain if the support guys are unable to produce an adequate 'how to reproduce the problem' document for the programmers.
The way it works at our company is that the testers are asked to verify the client's issue, i.e. trying to reproduce it and document the steps taken to reproduce it. Then it gets logged as an official bug and assigned to a developer who can retake the tester's steps and hopefully fix the bug.
Testers can identify an issue. How can they resolve the same? Only the developer will be able to do it. Looks really strange where a tester is asked to resolve the issue.
Who deals with the clients? Liasing with clients is not a task normally associated with the technical staff.
You should have someone whose role it is to speak to the customers, find out exactly what the issue is and how the client would like it resolved so that it may be passed onto the most relevant person to address the issue.
Testers - verify that the problem exists. Programmers - solve the problem.
In between there is another part to this, which is "gather information about the problem". Usually this is a split between testers and programmers; exactly how balanced that load is depends on the team.
If you don't have the code, you can't fix bugs. It's as simple as that. At the very most you could fix configuration errors, but if the misconfiguration was caused by the program that's a short-term fix.
发布评论
评论（7）
我通常希望管理层经常（比如每周）检查一下问题，并根据时间表、严重性、即将发布的版本等进行分配。一些问题是：
我不相信你可以孤立地解决这些问题。它要求项目经理等了解项目方向，程序员了解代码库，共同确定如何/何时解决问题及其对其他工作流程的影响。
I would normally expect management to look through the issues every so often (say, every week), and allocate depending on schedules, severity, forthcoming releases etc. Some questions are:
I don't believe you can resolve these issues in isolation. It requires project managers etc. with awareness of project direction and programmers with awareness of the codebase to work together to determine how/when issues should be addressed, and their impact on other work streams.
最初，您应该有一个支持部门来对所有新添加的问题进行分类。他们应该被赋予足够的权力和足够的信息来决定这是否不是问题、是否有解决方法或者他们是否不知道。如果是后者那么应该提升为程序员。
如果支持人员无法为程序员提供足够的“如何重现问题”文档，您可能还希望将测试人员纳入链中。
Initially you should have a support department that does triage on all newly added issues. They should be empowered and informed enough to decide whether this is a non-issue, whether there's a work-around or whether they don't know. If it's the latter then it should be elevated to programmers.
You might also want to include the testers in the chain if the support guys are unable to produce an adequate 'how to reproduce the problem' document for the programmers.
我们公司的工作方式是要求测试人员验证客户的问题，即尝试重现该问题并记录重现该问题所采取的步骤。然后它会被记录为官方错误并分配给开发人员，该开发人员可以重新执行测试人员的步骤并希望修复该错误。
The way it works at our company is that the testers are asked to verify the client's issue, i.e. trying to reproduce it and document the steps taken to reproduce it. Then it gets logged as an official bug and assigned to a developer who can retake the tester's steps and hopefully fix the bug.
测试人员可以识别问题。他们如何解决同样的问题？只有开发商才能做到这一点。要求测试人员解决问题看起来真的很奇怪。
Testers can identify an issue. How can they resolve the same? Only the developer will be able to do it. Looks really strange where a tester is asked to resolve the issue.
谁与客户打交道？与客户联络通常不是技术人员的任务。
您应该有专人负责与客户交谈，准确找出问题是什么以及客户希望如何解决问题，以便将其传递给最相关的人员来解决问题。
Who deals with the clients? Liasing with clients is not a task normally associated with the technical staff.
You should have someone whose role it is to speak to the customers, find out exactly what the issue is and how the client would like it resolved so that it may be passed onto the most relevant person to address the issue.
我想说，这样做的逻辑方法是：
让测试人员解决问题并不常见，因为程序员无法解决问题他们需要的反馈以避免将来出现问题。
I would say the logical way to do it is:
It's not common usage to let testers solve the issues as the programmers won't get the feedback they need to avoid the issues in the future.
测试人员 - 验证问题是否存在。
程序员——解决问题。
其间还有另一部分，即“收集有关问题的信息”。通常这是测试人员和程序员之间的分歧；负载的平衡程度取决于团队。
如果没有代码，就无法修复错误。就这么简单。您最多可以修复配置错误，但如果错误配置是由程序引起的，那么这只是短期修复。
Testers - verify that the problem exists.
Programmers - solve the problem.
In between there is another part to this, which is "gather information about the problem". Usually this is a split between testers and programmers; exactly how balanced that load is depends on the team.
If you don't have the code, you can't fix bugs. It's as simple as that. At the very most you could fix configuration errors, but if the misconfiguration was caused by the program that's a short-term fix.