转 从测试角度看提升客户满意度

上一篇 / 下一篇  2012-12-04 16:33:58

原帖地址

http://www.51testing.com/?uid-478599-action-viewspace-itemid-830072

http://www.51testing.com/html/90/n-830290.html

9月份以来,常驻客户现场3个月,听到客户的抱怨,也感受到客户的心情,越是这样近距离的感受,就越是觉得,提升客户满意度,是个艰巨的任务。

在做测试工作的时候,一直被灌输一个思想,测试工程师是产品质量的把关者,要从客户的角度出发,本着提高产品质量的原则,使产品在最大容错范围内能够正常使用。提高客户满意度,就是提高产品质量。但是随着工作的进行,越来越觉得提高客户满意度这件事儿,贯穿于整个项目周期,需要整个项目组的人员,从项目经理,需求人员,开发人员,交付人员到测试人员,工程人员,维护人员,每一个岗位的人都需要考虑,这样才能真正达到客户满意度的提升。

就说我在现场的这几天吧,评论一下我们的产品,以下几个方面严重影响了客户满意度:

1.易用性不满足导致满意度降低。

原因:需求大方向明确,细节无人推敲。在使用过程中,业务部门的人员总会向我们提出零散的需求,比如:这个页面能不能做个导出,这个查询条件能不能给个默认值。这些易用性方面的小需求不满足,会导致客户满意程度的降低。就像综合查询,客户总是希望能做的更灵活,更易用,现在在使用确认的已经是第三版。

分析:这应该是从需求细化方面控制不到位造成的。对于开发和测试阶段,仅通过一句话的需求,没有需求说明书,也无法把客户的所有需求都考虑到,只能凭经验。更重要的是本来业务不熟练,更没有很多时间去考虑,所以,但也没有很好的建议,这种情况下最好能够有文档,这就需要需求人员在沟通的时候多注意细节,以此来提升客户满意度。但是的确时间是硬伤。而且从开发和测试人员的角度来讲,这种零散需求会打乱我们的工作计划,这也是为什么两周就能收到30个升级包,导致工作超负荷的很大原因之一。

2.使用过程中错误频出导致满意度降低。

这个原因很多,大家都认为报错类的bug应该在测试环节都避免掉,我自己也把这些问题原因分析总结过,但发现80%的错误都是测试环节很难可能发现的。举几个例子:

a.某功能报错,找不到函数。

原因:开发调用了一个函数生成用户密码,这个函数是他们自己建了用来批量处理后台数据,引用了oracle自身的一个jar包,测试环境是同步生产库的,而在我发现错误的时候,开发只让我加载这个jar包,并说生产环境已经存在,由于是oracle自身的lib包,跟机器有关系,我也没关心他后台代码是如何实现的,就这样测试通过了。而后来发现生产环境并没有这个jar包,所以报错了,后来开发修改了实现方式;

分析:其实项目中的每个成员都应该有全局观,去探究这个接口到底应不应该这样用,这种问题应该在单元测试杜绝。

b.工作流审核通过后,下一个节点看不到信息。

原因:这是工作流物化视图刷新上的问题,偶现,但是一直没有解决过,后来去掉了工作流的物化视图;

分析:这些偶现的BUG,不能存侥幸心理。已经提了无数次的BUG,非要等到客户叫起来才修改。

c.人员上岗工作流审核通过后,没有做变更人员状态处理

原因:从界面录入,人员分类信息是必填的;但这个人员信息是从OA系统后台导入的,没有导入人员分类信息,而程序中对分类为空的没有做处理,这个分支在测试时也没有发现,因为根本不知道会从OA系统导入数据,所以产生BUG;

分析:我们需要了解更多的应用场景。



3.时间拖延导致满意度降低。

原因:这只能归结为资源不足了,现场的人都忙得手忙脚乱了。之前有一部分原因是对系统原来的架构不熟悉,原来的系统到处是陷阱,导致开发速度比较慢,现在已经好很多了;那些零散需求也是原因之一;一个很重要的原因就是出包一次通过率不客观,一个包退一个来回就得一天。

分析:资源不足永远是前期项目规划不到位的接口,项目经理应该注意去平衡资源与效率的关系。



4.系统性能导致满意度降低。

原因:很多,现场也正在做压力测试,并想办法改进系统性能。比如前台慢的改造为jsp页面,修改js加载方式,后台慢的做优化,加索引,改表结构。

分析:当初设计阶段没有考虑到客户满意度性能问题,后期花费较大的资源去整改,吃力不讨好。



5.对数据正确性有怀疑导致满意度降低。

原因:系统中的报表数据,除去算法上可能的偏差,再就是数据来源太多,从柜台/数据中心/手工导入数据/营销系统同步数据等等,而且有很多需要后台运行job来驱动数据采集和计算。其中要是有一个环节出错,得到的结果就无法预料了。现在的监控日志还不完善,客户看不到出错信息又觉得数据不对,产生怀疑是肯定的。

分析:不能图开发容易而省去步骤,授人与鱼步入授人与渔,要让客户了解系统的运行情况,日志监控必不可少,告诉客户怎么维护系统,总比每次都自个儿到现场查异常问题强的多。



以上这些问题已经让客户对我们的质量不信任了,客户也说我们测试不到位,作为一个测试人员,有时候一听到“测试”两个字,就会竖起耳朵,总认为出现问题可能是我没有测试好引起的,但现在越来越觉得,降低缺陷逃逸率,不仅仅是测试的事情。有时候需要项目组所有成员一起反省!


TAG:

 

评分:0

我来说两句

日历

« 2021-11-17  
 123456
78910111213
14151617181920
21222324252627
282930    

数据统计

  • 访问量: 3996
  • 日志数: 12
  • 建立时间: 2012-11-28
  • 更新时间: 2013-02-22

RSS订阅

Open Toolbar