我们在Polarion系统里面去管理那些缺陷的时候，是不可以单纯地把这些缺陷当成一张记录问题的表格来对待的；缺陷从最早的被发现，再到后面的确认、分派、修复，还有验证和最后的关闭，每一个步骤其实都应当被设置好清晰的状态，并且定好负责人、必填的空项以及流转的规矩；因为Polarion这个系统本来就是在一个网页里面去管理需求、开发还有测试这些东西的，所以缺陷的流程一般也会跟需求、测试用例还有测试的结果放在一起，组合成一个互相联系的体系。

　　一、如何对Polarion的缺陷流程进行设置

　　我们要先想明白：缺陷到底应该让谁来提交，接着由谁去确认，谁来负责修复，谁又来负责验证，而且在满足了什么条件的时候才可以把缺陷关闭；把这些流程都想明白了，后面的状态配置才不会越弄越乱。

　　1、把缺陷工作项的类型确定下来

　　项目成员可以先去检查一下项目当中，是不是已经存在了叫作【Defect】或者【Bug】的类型；如果发现没有的话，系统管理员就必须在工作项的分类里面重新添加一个缺陷的类型，还要把它的名字、图标、表格里的空格以及能用的流程都给配上。

　　通常情况下，缺陷工作项里面经常用到的空格包括了【标题】、【描述】、【严重程度】、【优先级】、【在哪发现的版本】、【被影响的版本】、【怎么重复出现的步骤】、【实际看到的结果】、【本来期望的结果】、【归谁管】、【连着的测试用例】还有【连着的需求】等等。这些空格不需要在最开始的时候就放进去特别多，但是像怎么重复出现的步骤、严重程度、被影响的版本这几个空格最好还是要留着，要是没有这些，以后找问题出在哪里就会感觉非常吃力。

　　2、对缺陷的状态进行设计

　　经常见到的缺陷状态可以被设计成【New】、【Open】、【Assigned】、【In Progress】、【Resolved】、【Verified】、【Closed】、【Reopened】还有【Rejected】。

不过并不是说每一个项目团队都要生搬硬套这些状态，如果团队的管理流程比较简单，就可以少弄几个状态；要是团队的要求特别严格，就可以多加几个像“等组织分析”、“等着验证”或者“往后延期处理”这样的状态；

　　3、把状态流转的规则配置好

　　不同的状态之间必须被明确规定好该怎么去变动。比方说，【New】状态可以被变动到【Open】或者【Rejected】里面，【Assigned】可以变动到【In Progress】，【Resolved】可以变动到【Verified】，接着【Verified】再被变动到【Closed】；要是测试人员验证之后发现失败了，它就会从【Verified】或者【Resolved】被变动回【Reopened】的状态；

　　二、当Polarion缺陷状态在流转时被卡住了该如何排查

　　缺陷的状态在流转的时候如果被卡住了，这往往并不是因为“系统出现故障了”，而是由于用户的权限不够、有必填的空格没填、工作流的条件不满足、链接的关系没拉对或者被后台的脚本校验给挡下来了；我们在进行排查的时候，不应该只盯着眼前的那个按钮看，而是必须要顺着流程的配置往回一步一步地去查找原因。

　　1、去查看当下的状态是不是被允许进行流转

　　我们要先去看一下这个缺陷目前到底是停在哪个状态上的，然后再去核对在这个状态下面，是不是被配置了可以点过去的那个目标流转动作。如果页面上找不到你想点的那个目标按钮，这往往就说明在这个状态下，根本就没有做这一条流转的路线。

　　2、去核对权限以及用户所属的角色

　　要是看到别人都可以正常地去操作流转，偏偏只有你一个人点不动，那这极大的可能就是权限方面出问题了；我们需要去检查一下当下的这个操作用户，是不是拥有这个项目里面的缺陷修改权限，同时看看他是不是属于被允许去点这个状态动作的角色，像测试组长、开发组长或者项目的管理员等。

　　3、去排查那些必须填写的空格以及条件的校验

　　在很多缺陷的流程里面，往往都会被设置一些必须要填写的空格；比方说，从【New】变成【Open】的时候，【严重程度】必须被填上；从【Resolved】变成【Verified】的时候，【怎么修复的说明】必须被写好；而从【Verified】变成【Closed】的时候，【验证的结论】也必须被补全；如果这些空格被漏掉没有填，状态的流转动作就会发生失败。

　　三、对缺陷流程中出现的异常该怎么去修复以及防范

　　缺陷的流程一旦在某个地方被死死卡住了，我们是不太建议直接去让管理员强制去修改这个工作项状态的；如果能把原因查清楚，最好就按照原因去修理，要不然的话，后面同样类型的问题还是会反复地冒出来。

　　1、把漏掉的空格填好或者把填错的值改对

　　如果是由于必填的空格没填才导致了流转动作的失败，我们就去把这些空格给补齐；例如把怎么重复出现的步骤、修好的版本、验证的结果或者关掉的原因给补上去；而且里面填进去的值也必须得和选项列表里面的规定对得上，不可以用那些早就被停掉不用的老选项。

　　2、对工作流的条件以及动作的权限进行调整

　　要是发现有某个流转的动作对项目里的所有人来说都没法用，那么管系统的人就必须去好好核对一下工作流的配置了；这里的重点是要去看一下去往的状态、原来的状态、被允许的角色、条件的脚本还有动作的函数是不是都被配对了。

　　3、通过查看历史记录来把卡住的地方找出来

　　当我们在排查状态没有办法正常流转的问题时，工作项的历史记录是必须要去翻看一遍的；在历史记录里面，我们往往能够看到状态是怎么变过来的、空格被改了什么、负责人被换成了谁以及大家写的评论内容；因为Polarion这个系统很早就可以自动把工作项状态变化时的流程信息给记下来，所以状态变动的时间也能被拿来当作分析流程和做统计报表的底子。

　　总结

　　Polarion里面缺陷流程设置的核心任务，就是必须把缺陷从最开始的提交确认，再到后面的修复验证给设计清楚。状态的个数不应该被弄得太多，但是那些关键的节点是一个也不能少掉的。当缺陷的状态在流转被卡住的时候，我们就要从当前的这个状态、流转的路线、用户的权限、必须填的空格、被藏起来的空格、工作流设置的条件以及历史记录这些方面去一项一项地排查原因；通过这些办法处理之后，缺陷的流程才不至于只是表面上把“状态改来改去”，而是能够真正把发现的问题给解决掉，并且把质量给追踪到位。