质量回溯常见问题（一）

1、举例:通过现场同事持续两周的通宵加班，终于抓取出现问题时的日志，通过分析发现……

      分析质量回溯是搞清楚问题原委，不是追责，在写分析过程中不需要诉苦。这样的诉苦只会让人觉得系统的可维护性做得好差。反之，站在审核者的角度，应该能够通过这样的描述发现系统存在的问题，而不是看到大家有多辛苦。

2、举例:管理根因分析:这个问题主要就是需求分析阶段产生的，开发和测试在确认需求的时候都没有完全考虑到全部的应用场景。

        分析：管理根因分析是需要给出从现象到本质的逻辑正确的分析过程，非常具体。上面这样没有分析过程，直接给出结论的情况，往往是不了解回溯的意义，从而不重视，敷衍了事;或者是根本就不清楚从需求到交付整个过程中每个环节的质量要求，无从下手分析。

3、举例：CI目前还未覆盖该种调用API执行xxx操作的场景，回溯认为该阶段没有问题。

      分析：典型的逻辑混乱，前半句话说的是CI阶段有场景覆盖不全的问题，后半段说没有问题，以子之矛攻子之盾，中间没有任何解释说明，我看着都尴尬，但作者似乎不觉得。