因为一直从事web产品的测试，我的观点并不一定适合所有的类型项目。

　　工作已将近三年了，虽然这三个年头里我都在积极的学习着与测试相关的技术；但是能沉淀的东西很少。相信测试同学都有类似的感觉。

　　不要为了测试而测试

　　前几天做了一个测试的PPT ，是讲项目中要用到的测试技术，总结了半天其实实际的产品中没什么技术，熟悉需求，转化成用例，待项目上线后验证功能OK 了；对一个自身质量要求不高的项目，我们有时候为了体现自己价值，非要在一些不痛不养的问题上揪着不放。

　　举个不恰当例子，某钢琴高手开了一个补习班教钢琴，家长送来一孩子目的只是让孩子学学钢琴；钢琴高手为了体验自己的价值（牛B），硬是按照贝多芬的标准去培养，孩子弹不会《XX交响曲》不让孩子走。先不说孩子有没有贝多芬的钢琴天资，也许孩子压根不想成为贝多芬。

　　当然了，如果你办的是“中国音乐家钢琴协会”，你有责任要求会员达到国际超水平，为和个人赢得荣誉。

　　有时候不要为了测试去测试，或为了体现自己的价值去做一些对整个项目贡献不大的事儿。当然，我在这里不是让测试人员放弃自己的原则。要知道不管是产品、开发、测试都是围绕着产品的发展贡献。

　　为贡献产品的发展测试远比为了测试了测试所带来的价值大得多；所以站在产品的发展上去看待测试工作更能体现自己的价值。

　　记得去年的总结再讨论自己对流程的理解。随着工作年龄的加长对这些问题也有进一步的看法；所以，再拿来炒一炒，希望能炒出新的味道。

　　没有好的开发测试流程，只有适合项目的开发测试的流程；

　　去年的一篇说软件测试流程，严格规范的测试流程一定比没流程好，敏捷的流程一定比传统的瀑布流程先进。这个观点没有大的错误，但是我们忽略了所做有产品这个“对象”；忽略了产品的特点与阶段。

　　例如两三个开发合伙开发一个项目（或产品），这时你让他们建立一套规范的流程，按流程实施，显然是不现实，我想摆在他们面前主要的问题是，如何快速的把客户需要的功能开发出来换成money ，维持生计以及公司运作。

　　例如一个各种功能已经成熟的项目，有着庞大的用户群，以维护为主的更新，它的版本功能的上线必须要建立严格的发布流程，经过充分的测试才能上线；用户群越大，暴露的问题越多，问题带来的影响也会越大。

　　同样是一个web产品，笔者目前所做的项目流程完全不是这样；我们的发布流程很简单，测试流程也很简单，不去写的规范又复杂的测试用例，放弃了使用缺陷管理工具来反馈问题；

　　沟通变得尤为重要；我不否认这样做会给产品带来了一定的风险；对于严重的问题，我们可以通过快速的版本回滚，对于轻微的问题，我们很快会在下个版本迭代中修复。是不是有点敏捷的味道在里面。

　　为什么会这样？因为这个产品属于前期开发阶段，很多功能还没上线。整个团队都在贡献着产品的发展；需要快速的将需求转化成功能给用户使用。

　　所以，没有好的开发测试流程，只有适合项目与阶段的开发测试的流程；

　　产品质量与用户容忍度

　　之前看过不少人讨论到底需不需要测试人员；我想说测试人员N年后不管是被重视了还是被淘汰了“测试的行为”永远不会消失；因为没有质量的产品基本上等于没有价值（也是说没存在的意义），至于对产品质量的要求是由用户容忍度决定的。

　　Facebook 没有测试人员！但是测试行为一直都在。开发找需求，开发、自测、发布，获得用户反馈，决定功能下线还是上新的功能---相当于一条龙的服务。因为用户的容忍度允许他这么做。

　　微软不能这么干，修复一个windows 的bug成本很高，而且用户是花钱买的，也许用户是用来创造价值的（办室、存储、管理），也许一个文件丢失，系统崩溃会给用户带来巨大损失；所以，微软需要很多的测试员。

　　拿修复成本与用户容忍度做标准，web产品优于客户端产品；在web产品中也要分行业；用户对银行系统、火车票、购物网站的容忍度显然要低一些，反过来说也是对产品的质量要求更高，因为与钱挂钩。算同一个产品，会员与免费用户的容忍度也是不一样的；因为会员用户有权得到更好质量与服务。

　　所以，关注分析用户的容忍度的测试才不会把自己变得格格不入。