测试人员和开发人员的工作质量标准.docxVIP

关于提交 Bug 的质量问题，测试人员提交的 Bug必须满足以下质量要求： 1） 必须准确地区分 Bug的 Priority （优先级） --- When log bugs, please try to use the following guideline. Cosmetic issues --- Low priority (like spelling, filters, etc.) System errors --- High or Urgent priority depending on how likely a user might be to run into it. System crashes --- Immediate // All others --- Normal [Caven] 若未达标 -1~-3 2） 报告出来的 Bug在 Description 中必须能 清楚准确地描述问题 ； 标准是客户和开发人员能看懂、不会产生歧义和误解； [Caven] 若未达标 -3~-5 3） 报告出来的 Bug必须可以重现 ，如有必要，重现步骤要写在 Steps to reproduce 这一栏里面；如果不能重现，请及时找开发人员沟通； [Caven] 若未达标 0[ 须证明确实不可重现 ] 或 -2~-4 4） 必须要准确地定位 Bug，要求 Summary中的描述直接指向问题所在处； [Caven] 若未达标 -1~-2 5） 关于 Severity 至少要明确区分 feature、 minor、crash 这三者： Feature--包括没有在需求中描述的， 不属于常识性错误的问题； 我们的建议； 客户的新需求等不在当前这期范围内的系统新特性； Crash---包括未处理异常、某个 screen 无法进入、某个功能无法使用等导致 系统或系统某个部分无法正常工作的问题； Minor ---其它的一般性问题； [Caven] 若未达标 -1~-2 6） 关于 Attached files，首先鼓励 尽量用语言把问题描述清楚 ，能不上传文件就不上传文件；若有必要上传， 尽量上传小的文件 ，除非迫不得已，不要上传大于 1M 的文件；（如果涉及到界面，还是贴一张图片比较好） [Caven] 若未达标 -1~-2 7） 报告 Bug 时应尽量 把相关联的地方一次性全部报告出来 ，一个现象在两个不同的模块中都有，就应当报告为一个 Bug； [Caven] 若未达标 -2~-4 8） 如果涉及到删除文件，应确保 vss 以及其他人电脑上的文件也删除了 ; [Caven] 若未达标 -2~-4 9） 新旧 Bug之间有关系的，关联最好加上 ; [Caven] 若未达标 -1~-3 关于修改 Bug 的质量问题，开发人员修改的 Bug必须满足以下质量要求： 1） 必须按照 Bug 的优先级顺序来修改 Bug；（有可能出现特殊情况，比如曹 bt 的 import ，如果出现特殊情况，要 及时和客户沟通说明情况） [Caven] 若未达标 -2~-4 2） 尽可能一次性把相关联的 Bug 全部解决 ；比如几个 List 都存在同样的问题，那么即使客户没有全部报告出来，解决时也应当全部解决掉； [Caven] 若未达标 -1~-3 3） 跟客户反馈时， 尽可能一次性把客户关心的问题说清楚 ，反馈次数越少，说明你的沟通效率越高，花在解决这个 Bug 上面的时间相应越少； [Caven] 若未达标 -2~-4 4） 自己负责的模块， when the specification has been completed or issues have been fixed 不应当出现异常或者明显的功能错误 ；若是由于关联模块被他人修改而 导致异常或者明显的功能错误，则可以谅解，但必须马上解决； [Caven] 若未达标 -3~-5 5） 代码和界面必须是符合开发规范的，一些关键算法和 [Caven] 若未达标 -3~-5  SP 必须是高效的 ； 6） 如果涉及到删除文件，应 确保 vss 以及其他人电脑上的文件也删除了 。 [Caven] 若未达标 -1~-3 7） 如果由于 修改这个 bug 而产生了新的 bug，应该减分 ？这种情况的发生是难 以避免的，但发生了是不好的。 [Caven] 应该减，扣分幅度视情况严重性而定； [Caven] 若未达标 -1~-3 Something Else--- About Issue ‘ Status ’ Feedback if we need customer to make comments; Assigned if we need customer to fix something