我很喜欢文中的那个希腊神话所说：“测试者在孤岛上，注定要不停地寻找不会存在，也不应该存在的东西，深信成功会为神带来不幸。”
我对这句话的理解是只要信念坚定，哪怕是神也抗不住！自勉～～
只要了解测试的人都知道，证明软件有错才是测试的王道。我也不去牵强地再去组织要关注失效理由了，就简单地举个例子，高速公路两旁都有护栏，而它们并不是行车的功能要求，路面就可以满足行车的需要，但为什么还要护栏呢？通过一段时间的测试可以知道，一般情况下，程序员在主体功能的实现上是不会有什么大的错误的，而经验老道的程序员几乎不会再主体功能的实现上出错，所以个人认为测试如果只是去验证主体功能可用，那么测试这个职业就不会被独立出来并得以发展。
以上的道理很多人都明白，也许和你合作的开发人员也明白，但现实和理论还是有一定差距的，测试员要较好地关注失效还是会被很多因素所限制，我遇到的主要有：
1. 管理机制的不合理、不完善
测试人员和开发人员是开发团队里的最大的矛盾体，在软件开发的过程中出现争论、互不相让是很正常的事情，而如果公司内部没有对应的评判人员（测试或开发经理），或者有评判权的人做了评判但并不重视，那问题就很有可能被搁置。也许这时作为测试者也只有将这个问题提交给需求人员，由其判定并加入到下一轮开发的需求中去了。
2. 项目发布时间紧，任务重
有时一个项目从开始到结束的时间很紧，而在项目计划中又出现了严重的偏差，而最终被牺牲的往往就是测试时间，一般的测试员不可能去和公司的利益对抗，服从是唯一的选择。这种情况下，测试员很难有多少时间去关注失效，通常只能在证明功能可用的情况下，把剩余的时间安排在验证重点功能是否会失效上。
3. 客户性质所导致的质量意识
客户性质这个表述我不确定是否正确，我想说的就是提出开发要求的客户是内部的（集团内部的其它部门）还是外部的，如果是内部的，常常会比较注重软件开发完成的时效，而如果出现小的质量问题，又都通过客服加以解决，有情绪但不会造成丢单危险，这也就造成了团队质量意识的随意，小问题往往不会被关注，常遇到开发人员的回应就是“用户不会这样操作”，当你苦口婆心地阐述万事皆有可能，防患于未然，那么得到的答复会是“等用户提出这个问题再改吧”。
版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。
本文出自souchy的51Testing软件测试博客：http://www.51testing.com/?200708
