我猜想和踢足球类似，还是那几个原因：
创新互联公司专注于忻府网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供忻府营销型网站建设，忻府网站制作、忻府网页设计、忻府网站官网定制、微信平台小程序开发服务，打造忻府网络公司原创品牌,更为您提供忻府网站排名全网营销落地服务。
人太牛： 不世出的天才，例如高德纳写书时发现排版软件不好用，就自己写了一个。也没听说他为这个软件项目请了什么独立测试人员。对了，他不读Email，有秘书帮他处理这些事——这也是一种分工！
有些软件工程师是在后台钻研和开发高难度的算法，或者做某种后台的处理工作，这个工作本身的难度较高，测试主要是自己通过工具完成。如果一定要找一个测试人员，这个测试人员的水平要相当高才行，如果水平那么高，那就不如也一起参与开发就好了。
事太小：“我写了个小类库，全部自己测试”，这当然不错。
但是如果由此论点出发，大力顺水推舟，推广到所有情况，从而得出“程序员就应该自己测试，专职测试不需要”这样的结论，明显不合适。
人不够： 那就自己动手多做一些事情，也挺好。就像前面提到的，一个人可以扮演多个角色。
无知： 这就不好说什么了。
引起网上讨论的两篇文章在这里：
http://sriramk.com/blog/2012/01/testing.html中文翻译在：http://www.aqee.net/on-testers-and-testing/。
http://www.quora.com/Is-it-true-that-Facebook-has-no-testers
其中打分最高的回答来自前雇员（Evan Priestley），他总结了Facebook这个公司为什么貌似没有全职测试人员：
a) 全公司人员经常使用自己的软件产品！（如果你开发的软件是航天飞行某控制模块，你怎么能经常使用呢？）
b) 使用log来分析问题可能出在哪里。（我们的一些程序员写程序都没有log，那大家看什么呢？）
c) 利用用户的反馈和实时状态分析（比较过去一小时和上周同一时间的数据来判断是否有bug。）
d) 应用开发商给Facebook报bug。（开发商其实比较不爽，但是FB有时就是无预警地修改API，你除了赶紧报bug，还能怎么着？）
e) 很多人自愿给Facebook报bug，这位贴主自称每月给他的前雇主报13,000个问题。（没错，是每月一万三千个！）
f) 最后这位前雇员还加了一句：还有一个原因是，Facebook大体上也不需要搞出太高水平的软件。
当你的公司也能有a）到e）这样的文化、流程、开发商和给力的前员工，而且你的软件“大体上也不要太高质量”，你的确不需要什么全职测试人员！
就像MSF原则讲的那样，有分工，有合作。微软开发测试主要有三种角色[i]：
SDE：Software Design Engineer，简称dev。
SDE/T：Software Design Engineer in Test，也写代码，但是重点在测试。
STE：Software Test Engineer。
对于如何更有效地开发互联网应用，微软很多团队都做过不少探索。微软公司在创业之初也没有多少专门的测试人员，在1984年的时候，开发：测试的比例是20:1. 后来随着产品线的变化，有些项目的测试人员比例几乎和开发人员一样多。最近，一些团队，是做互联网业务相关的，尝试把SDE和SDE/T合成一体。每个人都负责开发/测试/发布这一整套流程。这种做法，根据我的观察，有好处，也有额外的成本。
测试、质量保障、软件工程的质量，团队和个人到底应该怎么办呢？我认为，
在初始阶段（新项目，团队进入一个新领域，人员刚进入一个项目），每个团队成员都要尽量打通各个环节，多负责，把所有事情都搞懂，培养通才。
当项目/产业发展到一定阶段（进入阵地战的时候），要大力提倡分工合作，培养专才。同时，要把好的工具和流程集成起来，从每日构建，到基本功能的自动化，都要尽快实现。
把自己项目的架构和流程做好，让所有人都能比较容易地进行QA工作，这样，团队的“软件工程质量”才会有提高。
培养“大家都要做QA，专人负责量化的Test，有条件多做测试自动化”的文化。
要明白自己项目的特点，避免照搬别人的做法。不要听说某某伟大的项目的开发/测试比例是多少，因此就哭着喊着也要同样的比例。
如果一个团队是认真严肃地做软件，那他们一定要考虑如何保证程序的质量/软件工程的质量，以及达到这些质量，需要多少成本。
分工之后，每人负责一小块东西，怎么才能体现出个人的独特而巨大的价值呢？例如，你刚到一家出版社，领导让你做“二审”这份工作，或者你刚到一个软件公司，领导让你做“测试”这份工作，你怎么才能展现出你独特的价值呢？
请找到几个软件测试工程师（例如，软件学院的测试专业早几年毕业的师兄师姐，测试论坛上活跃的用户，软件公司的测试人员），和他们了解并探讨测试这门专业。
在本书开头我们讲了如何证明自己做好了软件工程：
研发出符合用户需求的软件
通过一定的软件流程，在预计的时间内发布 “足够好” 的软件
并通过数据和其他方式展现所开发的软件是可以维护和继续发展的
我们能否量化上面提到的这些要点呢？ 小组的同学可以想出一些指标，也可以从文献中查到学术界的论述，还可以通过实践来总结。
下面是一些常用的量化指标, 软件发布后发现的bug 的数量
软件 CC 后 DCR 的数量
用户的好评/差评 （例如AppStore 的5星级评价）
在CC 后发现的bug 的数量
文档的完备性和准确性 （用百分率表示）
修复 bug 所需的平均时间
单位开发量（人*月）出现的重大 bug 的数量
测试用例的覆盖率
模块的复杂程度 （用工具检测并有量化结果）
代码的行数
文档的数量和复杂程度
有多少代码被重用了
平均每天构建失败的次数
软件实现了多少功能点
软件能运行多久， 平均初次错误时间 （mean time to failure) 平均无故障时间 (mean time between failure)...
团队可以选取 7 个指标 （包括自己想出的指标），然后在项目中计算这些指标并跟踪。
[i] 这本书讲了不少微软公司各种角色的故事： How To Move Mount Fuji, 作者: William Poundstone, ISBN 0316778494
