工作已将近三年了，虽然这三个年头里我都在积极的学习着软件开发与软件测试的相关的技术；但是能沉淀的东西很少。相信都有类似的感觉。
不要为了测试而测试
前几天做一个测试的PPT，就是讲项目中要用到的测试技术，总结了半天其实实际的产品中没用到什么技术含量的技能，熟悉需求，并转化成用例，待项目上线后验证功能就 OK了；对一个自身质量要求不高的项目，我们有时候为了体现自己价值，非要在一些不痛不养的问题上用力过猛。
举个不恰当例子，某钢琴高手开了一个补习班教钢琴，家长送来一孩子目的只是让孩子学学钢琴；钢琴高手为了体验自己的价值（牛B），硬是按照贝多芬的标准去培养，孩子弹不会《XX交响曲》不让孩子走。先不说孩子有没有贝多芬的钢琴天资，也许孩子压根就不想成为贝多芬。
当然了，如果你办的是“中国音乐家钢琴协会”，你有责任要求会员达到国际超一流水平，为国家和个人赢得荣誉。
有时候不要为了测试去测试，或为了体现自己的价值去做一些对整个项目贡献不大的事儿。当然，我在这里不是让测试人员放弃自己的原则。要知道不管是产品、开发、测试都是围绕着产品的发展贡献。
为贡献产品的发展测试远比为了测试了测试所带来的价值大得多；所以站在产品的发展上去看待测试工作更能体现自己的价值。
没有最好的开发测试流程，只有最适合项目的开发测试的流程；
去年的一篇说软件测试流程，严格规范的测试流程一定比没流程好，敏捷的流程一定比传统的瀑布流程先进。这个观点没有大的错误，但是我们忽略了所做的产品这个“对象”；忽略了产品的特点与阶段。
例如两三个开发合伙开发一个项目（或产品），这时你让他们建立一套规范的流程，按流程实施，显然是不现实，我想摆在他们面前最主要的问题是，如何快速的把客户需要的功能开发出来换成money ，维持生计以及公司运作。
例如一个各种功能已经成熟的项目，有着庞大的用户群，以维护为主的更新，它的版本功能的上线必须要建立严格的发布流程，经过充分的测试才能上线；用户群越大，暴露的问题越多，问题带来的影响也会越大。
同样是一个Web产品，笔者目前所做的项目流程完全不是这样；我们的发布流程很简单，测试流程也很简单，不去写的规范又复杂的测试用例，放弃了使用缺陷管理工具来反馈问题；
沟通变得尤为重要；我不否认这样做会给产品带来了一定的风险；对于严重的问题，我们可以通过快速的版本回滚，对于轻微的问题，我们很快会在下个版本迭代中修复。是不是有点敏捷的味道在里面。
为什么会这样？因为这个产品属于前期开发阶段，很多功能还没上线。整个团队都在贡献着产品的发展；需要快速的将需求转化成功能给用户使用。
所以，没有最好的开发测试流程，只有最适合项目与阶段的开发测试的流程。
产品质量与用户容忍度
之前看过不少人讨论到底需不需要测试人员；我想说测试人员N年后不管是被重视了还是被淘汰了“测试的行为”永远不会消失；因为没有质量的产品基本上等于没有价值（也就是说没存在的意义），至于对产品质量的要求是由用户容忍度决定的。
Facebook 没有测试人员！但是测试行为一直都在。开发找需求，开发、自测、发布，获得用户反馈，决定功能下线还是上新的功能—相当于一条龙的服务。因为用户的容忍度允许他这么做。
微软不能这么干，修复一个 Windows 的 bug 成本很高，而且用户是花钱买的，也许用户是用来创造价值的（办室、存储、管理），也许一个文件丢失，系统崩溃会给用户带来巨大损失；所以，微软需要很多的测试员。
拿修复成本与用户容忍度做标准，Web 产品优于客户端产品；在 Web 产品中也要分行业；用户对银行系统、火车票、购物网站的容忍度显然要低一些，反过来说也就是对产品的质量要求更高，因为与钱挂钩。就算同一个产品，会员与免费用户的容忍度也是不一样的；因为会员用户有权得到更好质量与服务。
所以，关注分析用户的容忍度的测试才不会把自己变得格格不入。
提升自己的贡献
前面的东西貌似都在“弱化”测试存在的价值；俺本来就不被重视，所以俺就需要更加认真和努力找问题来提升自己存在的价值，你现在说，有些产品不需要太指着的去测试；那你说俺还能干啥？
当我们把测试看成是为开发和产品服务时，也许情况会完全不一样。我们可以提供哪些服务？
用测试发现产品的不可以测试性
前面已经提到队团不管是否有测试人员，但测试行为一定会存在；如果一个产品都不可测试，如何去发现并修复bug ，如何去维护与扩展？尤其对于web产品来讲，不可维护与扩展的产品无疑是致命的。（可以通过项目重构再解决）
建立产品质量的评估方法
为项目团队提供每个版本的bug趋势分析数据，让项目中的每个人都了解项目当前的状态
通过分析bug数据来建立或完善各种 Checklist，帮助项目团队更好的完成需求评审、设计评审以及代码评审，减少bug出现的机会。同时，可以定期将多个项目的Checklist进行合并，使单个项目的经验可以通过Test Team快速的流动起来，及时的作用于其他项目
主动为Architect Team提供每个项目的性能测试数据，帮助他们获取更多的实际项目信息，减少踏入“陷阱”的几率
建立可持续运行的测试框架
建立自动化测试测试框架；构建持续集成，使版本的迭代与更新得到快速的反馈。
建立关注开发质量的开发文化
没有测试人员自测节省人力的了，尤其在单元测试层面。产品的质量应该由开发与测试共同承担。（现实中的责任到人，让团队很难形成这种文化）
贡献产品发展
旧病成医，测试的产品多了自然会对产品有自己的理解，产品的定位，用户习惯与体验； 可以从测试的角度贡献产品的发展。（这个由产品的特点，公司文化决定）