Pra*_*. S 17 language-agnostic bug-tracking process
在我目前的公司中,测试和开发团队之间对于bug的严重程度尚不清楚？有些论据来回减少或增加严重性.我们现在还不知道任何列出规则的文件.测试人员根据他的直觉提出错误并分配优先级.开发人员会根据他的负载或其他因素请求更改.
错误的严重性/优先级如何分类？是否有任何标准可以指导如何根据客户需求,时间线和其他因素确定软件缺陷优先级？
big*_*ose 10
使用故意与严重性或影响无关的优先级,并仅描述计划中错误的概念位置.此字段将确定哪些错误可以处理,因此需要非常清楚错误的事实是否未公开进行协商.
使用故意具有与调度或优先级无关的具体,可验证定义的严重性级别.我已经成功地使用了Debian BTS使用的严重性定义,这些定义一般适用于编程项目.
这样,严重性更多地是一个可验证的事实,与优先权声明无关.该优先级是就可以自由地进行调整上下通过谈判也好,不影响的严重性领域的事实性信息.
试图将"严重性"和"优先级"混合在一个单独的领域中会导致灵魂消耗的争论和浪费时间.错误记者需要一个确实的事实指南来确定错误的"坏",这需要由独立的各方轻松达成一致.另一方面,优先级是谈判和安排游戏的正确目标.
我在紧急控制中心系统上工作,所以这组错误级别有点,很...... 极端:
这是我的头脑.如果你想知道,它是从最极端到最少:-)
| 归档时间： |
|
| 查看次数： |
5437 次 |
| 最近记录： |