今天Lily找我谈话，说到了由于Ticket Detail页面在3.0版本第一阶段中实现的方式下，对Ticket操作时整张页面会刷新给用户体验很不好，然后整个解决方案被推翻重做，致使Ticket项目比原计划延期很久。她问我当时是否知道该问题，我细想了一下回答说，我当时没有注意到这个问题，因为原先2.0的版本中，页面的处理机制就是这样的，所以并不觉得那时候的处理机制有什么问题。然后Lily就说，哦，原来是能力的问题，不是处理方法的问题。因为如果是知道这是个问题，然后作为Testing Leader，又没有提出这个问题没有去深究这个问题没有去负责驱动解决这个问题，那么作为Testing Leader，是不负责任的或者在问题的处理方式上是有问题的。但是如果是不知道这是个问题，那么是作为一个Testing Leader的能力问题。因为我还没有那个能力去发现这是个很严重的可用性问题，我自身的修行、经验、对产品的理解深度还不足以让我去发现这个问题所会带来的严重影响。
然后她又说到，领导经过讨论后决定追究责任，而黑锅最终落在了负责该模块开发的Jason身上。而她也表达了自己的观点，她认为模块开发人员Jason不应该承担主要的责任，主要责任应该在项目经理William，项目测试负责人我，还有测试部门经理Lily（她）身上。在这个问题上，我同意Lily的观点。我觉得把责任追究到Jason一个人的身上，这是不公平也不合理的。我作为测试负责人，对于项目上出现的问题无法察觉，这本身就是一个大问题，我也应该负很大一部分的责任。
然后Lily说到，如何尽可能的去防范这类问题呢。首先，我觉得这个问题的根源在于项目需求定义的时候没有确定好该模块的实现方式，没有考虑到这里的风险。如果有办法在定义需求时能考虑到这个问题，那么就能在成本最小的情况下解决该问题。如果这样的问题逃过了需求定义阶段，那么在测试阶段也需要发现并解决这类问题。那么，为什么这次会漏过呢？
我想主要原因有两个:
1，自己（包括整个Testing Team）对用户体验方面的了解和造诣不够
2，自己（包括整个Testing Team）对于既定的需求和程序的实现方式太过相信，无法提出自己的看法或者有看法不会据理力争而是很快的被打压下去。
所以以后的测试过程及项目管理过程中，要提高自己用户体验方面的知识，加大用户体验方面的测试，然后遇到觉得不对的或者设计的不合理的问题，要能够说得出想法，道得出理由，并将自己的想法继续坚挺的执行下去。如果开发人员有异议，则可以找项目负责人或更高的领导。只要你能说出理由，会有人听你的。当然，这不是我一个人需要做的事情，我们的测试团队所有人都要有这样的意识和行动。
然后Lily还指出了目前的测试团队还存在着许多的不足，比如团队凝聚力不够，许多事情没有一个标准，总结的习惯没有培养起来，没有适当的问责制度和绩效考核。她也希望公司能来一个比较厉害的测试部门经理来带领整个团队前进。
她还说不能甘于平庸，要不然很快很多年过去了，发现自己真的很平庸了。前几天刚好看到一句话，中庸之人，必成炮灰。