在那个项目里，所有的测试人员由于没有理解测试用例中一个期望结果的英文描述导致一个bug到最后才被一个新加入项目的同事发现并提出来。后来发现那个英文描述确实简单，但是客户却在某个bug的回复中明确的解释了那个意思。复测这个bug的同事没有足够的重视而忽略了。
说到这里，不知大家明白了意思没。估计有些朋友已经发现了问题所在。当时我的步骤如下：
.负责测试的同事。通过查看版本的测试结果找相应的测试人员。但后来发现由于中间有交叉测试，所 以所有的同事都测过。
.是否是需求变更。查询相关资料，结果无。
.是否有相似bug。查询bug库，果真发现一个相似的bug，并且客户在回复中明确的提到了那个期望结果的解释。
.找负责重测或跟踪bug的同事。回复因为是客户关闭的bug没有仔细查看及理解。
这时我自认问题找到了，将问题告诉了客户经理。虽然是自己的项目出问题，但是我觉得是测试人员的问题，没有自己的问题。由于那个bug比较严重，而且估计用户会在以后的使用中发现，所以就告知了客户经理一起商量决定这个bug是否要补报。
客户经理还是比较老道，而且从她的角度看了看这个问题。当时就让我倍感冰冷。
1．首先期望结果的描述过于简单。不过它来源于功能说明书，直接从那里面搬过来的。那么当时负责写测试用例的人应该检讨，为什么对于这种模糊的定义没有提出及询问客户？
2．然后就是对bug没有做好跟踪，一些实际上可以看为是需求解释、变更或设计变更的客户回复没有收集且发布给所有的参与者。
3．最后对需求解释、变更或设计变更没有进一步测试。
好了，由于我和她是平级，别人也不好意思明着指责你的不是，但是通过她所指出的问题，我在心里实际上已经发现自己的很多问题了。
1．首先没有询问测试设计人员是否有模糊或不清楚的地方，收集且询问客户。没有充分评审测试用例，导致需求模糊，用例也模糊的局面。
2．没有对bug的统一管理，没有回顾bug，整理客户在回复时的解释和变更并告知所有的同事。
3．没有组织且展开进一步的测试。
后来针对上面的问题，我也采取了相应的纠正措施改正了。但是那次让我深深的感到了对于项目而言，没有问题是和管理无关的。而且作为项目经理，千万别在出现问题时还分是你的错还是其他人的问题。对于项目经理来说，一切错误都和你有关，在查清问题之后说明问题的起因固然重要，但自身的检讨和如何改正才是最可贵，而且让其他人不会觉得你再推卸责任的嫌疑。那样只会让你的合作者鄙视和让你的组员更加的难受。
最后借一句话自勉“真正的管理者必须有择善固执，据理力争，勇于认错，接纳指正，不推卸责任的精神。”
//
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/