如果说一定要找一个最关键的能力，那就是责任心了。这是针对不太规范的测试而言，对于理想状态的测试，如果测试案例都定好了，测试人员按部就班执行就好。但一般来说，测试方案都是粗线条的，那么做一个案例还是做两上，猜测还是不猜测，都是测试人员主观需要确定的，这时，有责任心的测试的价值就体现出现了。

　　我不建议测试人员自己动手处理BUG，开发人员和测试人员形成的相互制约在一定程度上保证了软件的质量。测试人员如果自己处理BUG，引入新的BUG的概率会大增，而且发现这样的BUG要比发现开发人员制造的BUG难得多。

　　同样的道理，开发人员测试也会造成相互制约机制的破坏，因此，有条件的软件公司最好不要让软件开发人员测试自己的软件。但这也有一点例外，就是开发人员用白盒测试工具自己检查自己代码的质量，这样的测试还是建议开发人员自己做的。

　　（4）我们经常看到一款软件在正式发布后，仍存在很多Bug。在产品发布后，是否还需要人员去进行测试Bug？对一款产品的测试工作，Bug率达到一个怎样的状态才算作合格产品？

　　即使软件再也不打算升级了，只有还在使用，测试就还有意义。测试可以为下次升级做准备，即使不再升级，测试也能给使用者以信心，对于存在的问题，给出解决或预防的办法。更主要的是，用户一定会发现问题，开发人员要么根据测试人员的复测情况进行修改，要么就只能教育用户怎么避免问题了，比如：“那个地方千万别输入负数，否则系统会崩掉了”，多丢脸呀。

　　而如果一个软件行将就木了，不仅不会再改，甚至不会再用了，那就别测了。

　　Bug率多高跟软件给谁用有关，飞机火箭的BUG率要求肯定要比办公软件苛刻得多。套用一句据说是某快餐店销售人员的话：“给冰激淋的量应该是客户不投诉的最少量。”那么BUG率就应该是客户还愿意选用你的软件的最高BUG率就好了。对于一般软件来说，这完全是个市场行为，客户能接受，项目经理一定不会再投入测试人员了。而如果你的对手重重，或你有一个很有追求的上司，那么BUG率就会要求得比较严格。而对于飞机火箭来说，由于硬件投入大，政治影响大，事关人事等原因，BUG率的要求会非常苛刻，测试投入也应该大得多。

　　（5）您认为测试人员有没有必要与开发人员在同一个项目组工作，能将Bug扼杀在萌芽状态吗？如果采用这样的工作方法，责任应该如何界定，避免互相推诿？

　　将BUG扼杀在摇篮里是我们的终极追求。上面的问题谈到开发人员可以利用白盒工具检查自己的代码，这样就可以在代码还没有离开开发人员的手里的时候就杀掉它。在一个大型开发项目中，测试可能有很多的角色，如开发测试，为开发人员贴身服务，独立于测试，跟开发人员背对背，跟踪每一个研发版本，在发版前还有一个测试组，这个测试组发现的问题就要打开发和测试组的板子了。软件发版后，再有一个测试组，专门针对用户的反馈进行测试，将认为必要的改动记入下一个版本的需求中。

　　不管测试和开发是在一个项目组中还是完全独立，出现推诿的原因一般是因为测试和开发上面共同的领导工作缺位，没有一个老大说了算。测试人员发现开发人员的问题天经地义，似乎开发人员没有反驳的余地，但测试人员也会有“水平有限，错漏之处，敬请谅解”的地方，这要是让开发人员揪住，当然会出现界定责任的问题。这就需要有一个站得更高的人，充分了解软件的需求和设计，由他来充当裁判，一方面保证开发人员按要求修改问题，一方面把测试人员提得不合理的问题驳回，主持公道，解决争端。