ALM Soft里的缺陷管理和测试执行是连在一起的。测试人员执行用例时，如果结果未通过，可以直接从当前执行记录提交缺陷，这样缺陷会自动带上对应的用例关系；也可以进入缺陷视图单独新建缺陷，再补充关联信息。实际使用里，最容易碰到的问题是缺陷已经创建成功，但回头看测试用例时没有关联记录，或者在缺陷详情里找不到原来的执行用例。这类情况要先分清缺陷是从哪里提交的，再检查用例有没有进入测试轮次、是否已经执行，以及提交缺陷时有没有带上关联用例。

ALM Soft里的需求审批主要用来把需求提交、评审、通过或退回这些动作串成固定流程，避免需求还没确认就直接进入后面的研发阶段。流程本身可以调整，审批节点也可以指定给项目角色、具体用户或组织角色。状态卡住时，很多问题并不是需求内容本身有错，而是节点没有处理人、项目成员缺少对应角色，或者上一节点没有真正提交完成。

版本发布规划做得太粗，常见结果就是需求临时插入、测试时间被压缩，正式上线后又冒出一批没人认领的问题。处理“ALM Soft版本发布怎么规划ALM Soft版本发布后的遗留问题如何管理”，需要把需求、迭代、测试、缺陷和发布版本关联起来，让每一项工作都有明确状态和后续去向。

研发过程中遇到需求调整、缺陷修复或版本范围变化，通常都要先提交变更请求，再进入影响评估和审批。ALM Soft的具体字段可能经过企业定制，但整体思路差不多：把改什么、为什么改、影响多大和怎么回退写清楚，审批人才能快速判断。

在ALM Soft这种项目管理工具里面，权限角色的设置要是很不明确，就非常容易导致两种状况发生，一种是普通成员被给的权限过大，导致需求、测试用例还有缺陷被他们随意改动，另一种是权限被给得太少了，用户在登录之后居然连项目都瞧不见，虽然权限管理这件事情表面上是由管理员来负责的，但是项目协作的过程会直接被它影响到，特别是在多人共同去参与需求、开发、测试以及缺陷处理的时候，角色的分配必须提前去做好规划，可不能等问题真的发生了才去临时修补权限。

ALM Soft系统内的基线版本，主要功能就是把特定阶段的需求、测试用例、缺陷或者版本资料进行固定；在项目向前推进的过程中，需求会发生更改，测试用例需要补充，缺陷状态也会变化，如果团队不建立基线，后期管理人员就很难说清某个版本当时到底包含哪些具体内容；当基线建立清楚以后，项目团队可以拿它作为评审的依据，大家也可以在需求变更后进行差异对比，从而判断出哪些内容被新增、修改或者删除了。

在ALM Soft这款软件里面，关于测试用例方面的管理工作，其实不单单是把那些测试的步骤给填进去；更关键的任务在于，要把项目里的要求、测试的条目、最后测出来的结果、还有发现的错误记录，全部都紧密地结合在一起，这样在项目快结束的时候，人员才能看明白哪些要求是已经测过的，哪些地方还没有被测试照顾到，以及哪些毛病需要退回到开发人员那里去重新弄。要是测试的条目只是乱七八糟地堆在系统里面，虽然短时间之内还能勉强应付着使用，但是日子一旦长了，就会遇到找不到条目、来回重复编写、弄不清到底有没有把要求都测完之类的问题。

在用ALM Soft管理需求的时候，很多问题其实不是因为大家不会用这个工具，而是因为最开始没有把需求放对地方，字段写得不清楚，层级也没有统一，如果最开始建需求太随便了，后面评审、开发还有测试工作就都会跟着变乱，特别是需求树的层级如果混在了一起，表面上看只是目录不整齐，但实际里面会影响到需求的追踪、测试的覆盖还有变更的管理，所以我们在用ALM Soft的时候，得先把需求条目建清楚，而且层级关系也需要定期去收拾。

在项目人员利用ALM Soft去管理需求的时候，大家会碰到的许多麻烦，其实并不是因为这个系统不会操作，而是大家在刚开始的时候，就没有把需求塞进正确的地方，相关的字句字段也没有写得太明白。在操作ALM Soft软件的时候，项目人员必须得先把需求条目给建得明明白白，而且这些层级关系，大家也得隔一段时间就去重新理一遍。

当项目进入测试、验收和发布这些环节之后，要是还单靠一份任务清单，其实很难看出来那些关键的时间点是不是已经偏离了原来的计划，所以关于在ALM Soft里面怎么去设置里程碑，以及里程碑要是延期了又该怎么发出预警，就需要把截止日期、交付内容的范围，还有各项关键指标的门限值摆在一起去配置；里程碑跟一般的普通任务不一样，它更像是摆在发布时间线上的一个个检查站，专门用来判断像代码冻结、集成测试收尾、版本正式发布这样的节点，是不是真的满足了可以往下一个阶段走进去的条件。