目的:
|
将变更请求信息输入到跟踪工具中,以进行评估、管理和问题解决。
|
差别指示目标测试项中存在潜在缺陷,应输入到跟踪系统中作为事故或变更请求,并指明可以采取的适当纠正操作。
子主题:
验证是否存在可用的精确支持数据。整理数据以直接附加到“变更请求”,或者如果数据能分开地获取,则在变更请求中进行引用。
只要可能,就验证问题是否是可重现的。可重复出现的问题被开发人员注意到,并随后进行修正的可能性要大得多;而不能重复出现的问题则容易使开发人员泄气,且会将宝贵的编程资源浪费在毫无成果的研究中。我们建议您仍记录这些事故,但请考虑将不可重复出现的事故与可重复出现的事故分开标识。
对于变更请求,它的可理解性很重要,尤其是标题。请确保标题的有力简明,清楚地表明特定的问题。简要的标题对于摘要缺陷列表和 CCB
状态会议中的讨论很有用。
变更请求的详细描述应是明确的,并便于解释,这很重要。一个好的主意是尽可能早地记录您的变更请求,但在提交开发人员复审之前,再花时间回来改进和扩展您的描述。
尽可能多地提供候选解决方案。这有助于减少描述中其余的模糊性,通常有助于进行阐明。它还确保了能提高解决方案接近于您的预期的可能性。而且,事实表明测试团队不仅准备好查找问题,而且还能帮助确定相应的解决方案。
要包含的其他详细信息是:屏幕抓图、测试数据文件、自动测试脚本、诊断实用工具的输出以及任何其他可帮助开发人员隔离和纠正底层故障的信息。
就问题的严重性向管理和开发人员提供指示。在较大的团队中,实际的解决优先级通常留给管理团队确定,不过您可以允许个人指明他们首选的解决优先级,然后在必要的时候进行调整。作为一般规则,我们建议您在缺省情况下为变更请求指定一个平均的解决优先级,并在必要时根据情况升高或降低该优先级。
您可能需要区分以下两种影响:变更请求对生产环境的影响(如果变更请求未解决)以及变更请求对测试工作的影响(如果变更请求未解决);对于管理团队,了解缺陷何时影响测试工作与了解缺陷对用户的严重性同等重要。
有时难以预见为何您同时需要这两种属性。可能存在这种情况,即某项事故可能的确很严重(例如系统崩溃),但再现这种事故所需要的操作发生的可能性很小。 在这种情况下,团队可能将其严重性指示为高,但将其解决优先级指示为很低。
事故常常应验了一句老话“有烟必有火”。在您识别和记录一个变更请求时,您常常识别了需要解决的其他问题。避免简单地将这些附加的发现添加到现有变更请求:如果信息直接相关并有助于更好地解决现有问题,则可以这样做。如果其他问题不同,则根据现有 CR
识别它们可能会导致对那些问题不起作用,得不到它们自己权利的优先级,或者影响解决其他问题的速度。
|