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