扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
我猜想和踢足球类似,还是那几个原因:
创新互联主营丽江网站建设的网络公司,主营网站建设方案,App定制开发,丽江h5微信小程序搭建,丽江网站营销推广欢迎丽江等地区企业咨询人太牛: 不世出的天才,例如高德纳写书时发现排版软件不好用,就自己写了一个。也没听说他为这个软件项目请了什么独立测试人员。对了,他不读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
另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流