14.1 有些成功人士或公司认为不需要独立的测试角色（Test），你怎么看？
就像很多事情一样，不能把所有的事情说得太绝对了，举个例子来说，大多数的软件开发都是以小组的形式来进行的，每个人分配了一个模块，如果说每个人对自己的模块都进行一下测试，当然这样的情况下可以不需要独立的测试角色，编程的过程就是不断对自己的程序排错、测试来完成的，但是最后所有的模块整合成一个大的系统，这样如果程序员只对自己的模块进行测试，是肯定不能满足需求的，这时候就需要一个独立的测试角色，对整个系统进行规模测试，在不知道内部编码状况的情况下进行测试，反馈给程序员，最后做出一个完整并满足用户需要的系统。
14.2 为什么一些成功的公司不用测试人员
看了一些资料，邹老师也说了好多自己的观点，我自己对这些不太了解，但是我阅读的这些资料中，有一段话还是蛮认可的：Sriram Krishnan：“开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试，全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这“不归我管”，那你需要更好的程序员。”
14.3 测试人员的职业发展
看到这个问题，特意在网上搜了一些大家的看法，我也有一些感想。
第一、 不断改进测试策略，提高测试效率和质量改进测试策略需要掌握开发技术，但是技术仅仅是必要条件，更重要的能力，是能够系统的规划一件事情，分析工作中的问题，选择最有效的解决方法，最终和大家一起实现一个共同的改进目标。改进测试策略一般会考虑以下几个方向：单元测试（白盒和灰盒）、自动化测试、性能测试、安全性测试、易用性测试等等。当然，具体的改进目标，要根据业务的不同，选择合适的方向。
第二、 能够“吃”业务，控制业务的测试质量。测试人员吃掉一个业务以后，可以把测试工作完全交给另一个测试人员来做，同时，也能保证测试的质量。而要达成这个目标，关键就在于文档。我们需要以业务为单位，完善测试用例、业务沉淀、测试设计、测试脚本等文档，并且，更重要的是，要把这些零散的文档组织成一个系统的文档体系。
如果以后有可能从事测试工作，可能会对这个有更深入的了解。
14.4 如何衡量软件工程的质量
除了邹老师说的那些，我认为还有以下：
a)bug的严重级别--严重的bug会使用户无法使用软件更别说能接受这个产品了
b)测试用例的密度--用例密度直接影响bug的数量和严重级别
c)客户反馈缺陷，即漏测