年初的一个PPT,围绕着软件测试整理出来的几个观点

 

全面测试

    已发布软件的所有功能都将进行测试,如果不是由我们自己测试,那就要由最终用户测试。为了避免这种情况发生,我们要对软件进行全面测试,无情测试。

    一定要期待我们的软件当中有问题,测试是努力发掘这些错误的过程。测试是技术,更是一种态度。要理解和接受我们自己肯定会犯错,关键是要尽早发现,在发布前修复它们。任何软件团队都会犯错误,优秀的团队有勇气面对自己的错误并不断改进。

 

早测试,常测试

    随着项目的进行,软件的功能越来越多,越来越复杂,发现遗留BUG的成本就会越高。一个BUG存在的时间越长,发现他的成本就会越高。

    我们可以进行增量迭代式开发,完成一个模块的编码后就要进行充分测试,持续集成。写一点程序就测一点,早测试、常测试,去降低发现bug的成本。

 

加强研发内部测试(成本考虑)

    我们假设一方测试后修复一个bug的成本是1,那么二方是3,三方是10,到了客户那儿发现的问题,它的修复成本就有可能达到100。越靠近我们研发,牵扯的人员越少,造成的影响越小,修复成本也越低。越往后,不仅仅是修改代码的时间成本,还要加上人员之间、部门之间、客户之间的沟通成本,还要有客户关系损失等这些高昂的隐形成本。最理想的情况就是发现和修复缺陷的人就是制造缺陷的人。想要提高效率,就要将测试的工作量向上游推进,加强研发内部测试。

 

加强研发内部测试(项目进程考虑)

测试驱动项目

    测试可以作为项目的心跳去驱动项目的进程。我们开发一个功能,只有完成了测试,我们才能这个功能完成了。测试是集成在开发中的持续行为,而不是单独的活动。传统上,我们很自然地会更重视编码,但只要提升对测试的重视程度。为测试所付出的努力,一定会收到事半功倍的效果。

测试获取项目状态

    测试衡量当前项目产出、度量质量、暴露项目风险、为我们提供持续反馈,我们要利用这些反馈去调整项目前进的节奏和方向,控制项目正常进行。反馈非常重要,反馈的越早,留给我们的时间越多,我们的风险就会越低,反馈的越频繁,我们改进产品、积累经验的机会就会越多。一方测试为我们提供这种最直接的反馈。

    以上说明的是我们研发内部测试的重要性。软件开发与足球比赛有一点相似,就是防守做的好的球队,一定不是仅仅依靠几个优秀的后卫,从前场丢球后的反抢,防守就已经开始了。测试也一样,要贯穿到整个开发进程。

 

第三方测试

    研发面对三方测试要建立我们的乙方心态,将验证组看做是我们的最终客户。提交三方测试前一定是研发内部进行了充分测试,主观认为软件已经达到了可以直接下发到客户使用的程度。

    不要依赖于验证组,当依赖于别人帮我们发现错误的时候,我们犯错的勇气和概率一定会更大。将验证组看做是最后一道防线。清楚他们的重要性,但不依赖验证组。不依赖于验证组发现我们基本的程序错误。要将三方测试发现的每一条BUG当成是我们的研发的意外收获和额外收获,要反思为什么我们没有发现。一个事实就是:我们提交的质量越高,他们的起点就会越高,最终我们产品的发布标准也会更高。

 

产品发布

    产品发布的同时,也发布了我们的名声。团队的名声在公司内部传播,公司名声在客户中间传播。只有实现公司内部的部门之间的客户满意度,才能有公司外部的客户满意度。研发团队和测试团队都要对发布的产品有信心,测试就是帮我们是建立这种信心的过程。

    如果我们付出努力,不轻易妥协。即使用户还能反馈bug,那我们也只能接受,下一个轮次继续改进。测试也是资源的综合权衡。不存在完美软件,但我们可以训练我们自己发布足够好的软件 --- 对于当时的时间段,当时的市场环境,对于未来的开发者,关键是对于我们自己内心的安宁来说足够好。

    每个人都会犯错,人们一般可以原谅错误。我们所处的行业也不是对错误零容忍的行业。关键在于我们的产品给客户留下的什么样的印象。如果我们以往的记录良好,偶尔犯错客户也能容忍,但如果我们没有一个良好的记录,或错误太多或作为市场后来者,那想要扭转这个局面,我们就要付出比一开始成几倍的努力。

 

测试的扩展

    前面关注的这些只是软件测试中的程序方面的测试。像需求评审,架构评审,界面评审这些都是软件测试。并且这些阶段引入缺陷的修复成本会更大。

    任何时候只要我们想提交或发布一些东西,那这些就需要有测试。不管是对内还是对外,阶段或成品。同样对于软件测试的认识和态度可以扩展到其他领域。我们发送一个电子邮件也需要进行测试。

posted on 2014-03-29 13:23  敏捷路上  阅读(503)  评论(2编辑  收藏  举报