所谓的成就感,想想我们測过的那些功能

晚上电话和同事讨论一个工作上的事情,结束的时候聊起这种一个话题,全然是有感而发,也认为心有戚戚焉。

不是什么非常特别的事情,就是我们每天在做的工作,測功能。測版本号,然后公布。每一个月在做。每周也在做。正是由于这种寻常。非常多时候我们就仅仅看到这个工作本身。

想想这种两种状态吧:

1. 我们非常理解为什么要做这种功能,有什么意义(实际意义,战略意义也好),认可或者部分认可它的价值。

做完了,上线了,有人告诉我们这个功能有多少人在用,带来了什么效益(新用户,PV/UV,订单,交易额)?

作为实际的參与者。我们被尊重和感谢。

有哪些成功的地方,哪些值得优化的地方,下一步的计划是什么?对公布时间有什么要求?

2. 被告知要做这种一个功能,然后要求在什么时间点公布。尽量压缩开发和測试的时间,请大家尽力支持。实在不行就安排加班吧。

上线后,继续做下一期。或者下一个功能。

事实上不仅仅是測试。对于开发也是一样。

以上两种状态会不断的反复。对照下这两种状态吧。第一个更像是一个參与者,一个创造者。而另外一种,即便不是外包。事实上也非常像是外包。我对做外包的人没有偏见。可是始终认为外包这样的模式做不出优秀的东西,基于体制和人性。

近期有一个观念,全部依赖于人的服务行业,比方餐饮,中介,软件研发,事实上都是重度的依赖于人来创造价值的服务行业。

要想做好,一定是要想办法激发人的投入度。

刀塔传奇的公司莉莉丝的创始人王信文有篇blog(那些和钱有关的事 http://www.verypig.com/?

p=576)读起来非常有感受,比方这一段。“我细致想了想。发现了一条规律:假设是标准化商品,能省则省;假设是购买服务,那么想省钱经常不会取得好效果。


 确实如此,看看美国,非常多标准化的商品价格确实够廉价。和收入比。可是雇一个人就非常贵。我认为中国也是这个趋势。

这种样例还有非常多,比方海底捞,服务员被照应好了,客人就被照应好了,并且不程式化和冷冰冰。

再举一个中介的样例。能够拿北京的链家和上海的德佑比較下其它比較杂的一些。

激发人的也不仅仅是钱,至少大部分公司一年最多也就调两次薪,光这个激励能持续多久?又有多少人投入的去做一件事情之前会算一下我的薪资水平值不值得这么做?

非常多人都说自己仅仅是个打工的。事实上大家内心里都非常在意。我们做出来的这个东西有人用吗,cool吗,牛x吗?这本身就是工作的一种回报。

非常多人或许想说,我们一样能够制定各种各样的KPI,更细化的指标来考核,来衡量和要求服务和产出的质量。

这确实是一条应该走的路,可是是一条适可而止的路。不论什么一个经历过实际的项目或者带过一个稍大一点团队的人都会理解,假设那样真的可行。成功的项目和失败的项目就不会区别那么明显。

假设设定一个指标是要求内容装载到杯壁。那么就有可能得到一个丰满或者干瘪的结果,而这,取决于人。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvc3VwZXJxYQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" >

时间: 2024-10-29 19:10:04

所谓的成就感,想想我们測过的那些功能的相关文章

所谓的成就感,想想我们测过的那些功能

晚上电话和同事讨论一个工作上的事情,结束的时候聊起这样的一个话题,完全是有感而发,也觉得心有戚戚焉. 不是什么很特别的事情,就是我们每天在做的工作,测功能,测版本,然后发布,每个月在做,每周也在做.正是因为这样的平常,很多时候我们就只看到这个工作本身. 想想这样的两种状态吧: 1. 我们很理解为什么要做这样的功能,有什么意义(实际意义,战略意义也好),认可或者部分认可它的价值. 做完了,上线了,有人告诉我们这个功能有多少人在用,带来了什么效益(新用户,PV/UV,订单,交易额)? 作为实际的参与

人脸检測中几种框框大小的选择~

人脸检測应用极为广泛,内部细节也偏多,尤其是涉及到几种类型的框,这几种框的大小之前有着千丝万缕的联系,对检測性能的好坏影响程度大小不一.本篇文章基于自己在人脸检測方面的经验,说说对这些框之间关系的一些理解. 如今大部分人脸检測效果都已adaboost+LBP(各种改进)的方式实现,adaboost由N个强分类器组成,每一个强分类器由M个弱分类器组成,而每一个弱分类器事实上就是一个特征. 本文以LBP特征为例,人脸检測共涉及到例如以下几类框: 1. LBP特征矩形框大小(极为重要) 2. 检測框大

单元測试的优点

对于单元測试.我慢慢的用得多起来.前不久.还对这个东西朦朦胧胧,认为非常神奇. 如今,我认为单元測试真是极好的. 好在哪里呢?就是好来就是好! 靠,这又不是某D某主义,得讲理.怎么个好法,要说出理由. 好吧.我认为单元測试能够 1.保证代码质量 2.提高开发效率 比方说,这2天我与还有一位同事共同开发某模块.他搞前端,我写server端.他要调用我的方法. 开发是并行的,我在写方法的时候,他的界面还没好,那怎么确保我的方法正确呢?不可能等他写好界面,写好调用我方法的代码,然后我俩再一起測试吧?

关于迭代測试的一些思考

作者:朱金灿 来源:http://blog.csdn.net/clever101 一个软件的功能的越来越多,怎样建立一个规范的測试流程来保证对开发的功能进行充分的測试,是摆在我们面前的难题.在改动bug中经常会出现一种"按下葫芦浮起瓢"情形--改动了A模块的bug,却造成了原来測试没有问题的B模块出现了新的问题.这就促使我们思考:怎样保证測试的百分百的覆盖率.为此我设想一种迭代測试和迭代公布的流程.这个流程详细是这种:全部功能測试分为常规功能測试和新功能測试.所谓常规功能測试是指之前測

Selenium2 Python 自己主动化測试实战学习笔记(五)

7.1 自己主动化測试用例 无论是功能測试.性能測试和自己主动化測试时都须要编写測试用例,測试用例的好坏能准确的体现了測试人员的经验.能力以及对项目的深度理解. 7.1.1 手工測试用例与自己主动化測试用例 手工測试用例是针对手工測试人员.自己主动化測试用例是针对自己主动化測试框架.前者是手工測试用例人员应用手工方式进行用例解析,后者是应用脚本技术进行用例解析. 前者具有较好的异常处理能力,并且可以基于測试用例,制造各种不同的逻辑推断,并且人工測试步步跟踪,可以仔细定位问题.后者全然依照測试用例

软件測试基本方法(六)之集成測试和系统測试

在软件开发中.常常会遇到这种情况.单元測试时确认每一个模块都能单独工作,但这些模块集成在一起之后会出现有些模块不能正常工作.比如,在chrome环境下用js写了一个实时捕捉video中特定区域的模块,正常工作:利用worker线程进行webgl场景渲染,也正常.但是当两个运算合并时.出现一个模块不能正常执行,原因在于两个模块不适合在worker线程中结合.基于worker本身的局限性,仅仅能有一个模块正常工作. 所以,非常有必要进行集成測试. (1)集成測试定义: 集成測试是将软件集成起来,对模

C语言单元測试

对于敏捷开发来说,单元測试不可缺少,对于Java开发来说,JUnit非常好,对于C++开发,也有CPPUnit可供使用,而对于传统的C语言开发,就没有非常好的工具可供使用,能够找到的有这么几个工具: CuTest -- CuTest(Cute Test)是一个很easy的C语言单元測试工具.在使用它的时候,仅仅须要包括两个文件“CuTest.c CuTest.h”,然后就能够写測试用例,进行測试了.它对用例差点儿没有管理功能,报表输出也很easy,能够用来试验单元測试的基本想法. CUnit -

UI測试内容

我们在实际工作其中,针对web应用程序,也就是常常所说的B/S系统,能够从例如以下方面来进行用户界面測试: 导航測试 导航描写叙述了用户在一个页面内操作的方式,在不同的用户接口控制之间,比如button.对话框.列表和窗体等: 不同的链接页面之间,通过考虑下列问题,能够决定一个web应用系统是否易于导航:导航是否直观?web系统的主要部分是否可通过主页存取?web系统是否须要网站地图.搜索引擎或其它的导航帮助: 当然,这些同美工以及客户需求有关.我们是依据已经确认的页面进行測试就可以. 图形測试

软件评測师真题考试分析-6

2010年下半年试真题36: 软件測试原则中指出"全然測试是不可能的".主要原因是(). A.输入量太大.输出结果太多以及路径组合太多 B.自己主动化測试技术不够完好 C.測试的时间和人员有限 D.只靠黑盒測试不能达到全然測试 分析解答:全然測试是不可能的,由于不可能穷举软件的全部測试路径.输入有输出,所以本题的正确答案A. 2010年下半年试真题38: 下面关于设计功能測试用例的叙述.()是不对的. A.尽量用80%的測试用例覆盖20%的核心业务模块 B.功能測试用例中不包含功能的依