客户验收时,简单的按键使整个软件Crash了，你......怎么处理？

leevon

当客户验收时，你给客户演示软件的功能，然而一个简单的按键（比如Back键）操作，使软件Crash了，客户很不满意，你应该怎么办！
如果你是QA PM（测试项目经理），你会怎么做？
如果你是QA Engineer（测试工程师），你会怎么做？

板砖

不知道啊.

leevon

谢谢！
没人有处理办法么？

云层

原帖由 leevon 于 2007-12-6 09:43 发表
当客户验收时，你给客户演示软件的功能，然而一个简单的按键（比如Back键）操作，使软件Crash了，客户很不满意，你应该怎么办！
如果你是QA PM（测试项目经理），你会怎么做？
如果你是QA Engineer（测试工程师）， ...

如果我是演示的人，我这个时候直接去踢电源线，说电脑坏了，然后演示的时候跳过，其它的人重现好了，记录下相关的信息，查看这个测试负责人是谁，对应的测试用例是谁写的。
其实rp一般不会差到这个程度，因为程序写出来能运行还是基本能保证的

sunchunyue

楼上的那位，您也太强悍了~~~都能想出来踢掉电源？？佩服~~

   我个人觉得呢，如果是我的话，不管是作为QA PM还是QA Engineer，首先必须做的都是道歉，这是礼貌问题，毕竟没有能把握产品的质量是我们的失职。当然了，道歉要有艺术性，不能完全的就否定了本公司的成果产品。这样就会更加助长客户的气焰。然后并会保证会查明原因，并保证不会再出现类似的问题。（这种保证是一种信誉的象征，但是，前提是你要能够保证以后不要出现这样的问题，不然，信誉全失）
   总之，事情当时，发挥你的应变和交际能力，搞定现状。本人建议千万别踢电源，第一，踢不好会损坏公物。第二，是一种逃避的表现。治标不治本。第三，会有生命危险。呵呵

   最后要最的更加关键，就是你要在事后第一时间追查出开发人员和相关测试人员。因为这是他们的责任，很简单的操作就会出现问题，那么，负责质量把关的测试人员，就存在着更多的失职。

   不管怎么做，就是保证这样的事情不能再发生了，或者把发生的概率控制到极小的程度。

P.S：这样的问题比较少见，因为质量控制要是做到这样的话，我觉得，就有必要撤销这个部门了。……

[ 本帖最后由 sunchunyue 于 2007-12-10 17:03 编辑 ]

hgl

楼上说的真好

zhang88614

但愿这种事情不要发生，一旦发生，虽然你有备份的东西，但公司的形象可就完蛋了。

luoyear

原帖由 leevon 于 2007-12-6 09:43 发表
当客户验收时，你给客户演示软件的功能，然而一个简单的按键（比如Back键）操作，使软件Crash了，客户很不满意，你应该怎么办！
如果你是QA PM（测试项目经理），
---
作为结果去承受，我想，必须和客户坦诚，说明这个问题确实是没有被测试覆盖到。然后请求客户的原谅并道歉。如果有可能的话，重启应用重新演示。---
如果你是QA Engineer（测试工程师）， ...

当然，对于用户验收这样的活动，我们不仅要求系统测试时候去评估我们的测试覆盖率以及缺陷趋势，从而做出是否放行的决定。同时还要做好以下三件事情以确保用户验收测试的顺利通过：
1，必要的时候，能依据UAT Case在内部利用生产数据补充一轮测试；
2，不考虑Case，利用1-2天做随机性测试；
3，条件容许的情况下，预演一次UAT环境部署并覆盖主要的功能场景，以便在客户现场不丢丑。

hellen_ma

study

云层

要明白在客户面前出现致命的问题影响很不好的不是道歉能搞定的，这个时候要灭杀证据！

很多演示活动中出了问题都可以这样解决，直接关电脑，然后找借口就行了！只要你动作快，用户不一定能反映出来是系统的问题。

想当年我的boss在一次有名的招标会上演示产品就出了个问题，好像是算出来的金额有问题，结果一出来下面还没看清楚的瞬间他把电脑重启了，最后那个项目还是谈下来了！

崇拜死了！！！

当然还有一个朋友给我了另外一个看起来更好的方法

我现在演示一下如果我们的软件因系统问题一但crash的处理机制. ******** 请大家等一下.我们来换一台系统正常的机器.

[ 本帖最后由 云层 于 2007-12-11 17:18 编辑 ]

czqiqi

既然发生了问题，那就说明你的软件确实存在某些漏出的BUG，如果只是想办法逃避的话，这些问题终究还是会暴露在用户面前的。最后的方法就是勇于承认错误，拿出你的诚意，拿出你的真诚来挽回你在客户心中的形象。过后，分析问题发生的原因，测试设计有问题还是Tester的问题。
当然，如果一个程序烂到这种程度的话，只能说明开发或者测试的流程出现了最根本的错误，这个才是致命的

muler

如果出现这样的情况的话，首先是看一下这个问题是不是能重现，Crash当然是很严重的，但是可能并不是软件本身所导致的，可能是也其他的软件不兼容，可能是硬件配置的问题，也可能是偶然发生的，如果在客户那边能重现的话，了解客户的机器配置及软件的详细信息，在分析是我们的测试用例没有覆盖到，测试的环境不到位，还是测试人员没有尽到责任，最终解决问题，给客户一个明确的答复。
BTW：测试人员不要将思维光局限在测试用例上

leevon

原帖由 云层 于 2007-12-10 15:48 发表


如果我是演示的人，我这个时候直接去踢电源线，说电脑坏了，然后演示的时候跳过，其它的人重现好了，记录下相关的信息，查看这个测试负责人是谁，对应的测试用例是谁写的。
其实rp一般不会差到这个程度，因为程 ...

直接踢电源？呵呵，很好，很强大！不过，咱们要讲求和谐，很和谐的那种，呵！
事后倒是要好好处理哦！
rp这个很难说哦，说不定啥时就真碰上了，呵呵，思考多的话，也有个准备嘛~~~~

leevon

原帖由 sunchunyue 于 2007-12-10 17:01 发表
楼上的那位，您也太强悍了~~~都能想出来踢掉电源？？佩服~~

   我个人觉得呢，如果是我的话，不管是作为QA PM还是QA Engineer，首先必须做的都是道歉，这是礼貌问题，毕竟没有能把握产品的质量是我们的 ...

说的很不错噢，学习了，谢谢！
首先，要有艺术性地道歉；其次，要给与带有风险性的承诺！
事发当时要通过合理的办法搞定现状，之后要避免类似问题重范或发生率降到最低！
这样的概括，Ok么？呵呵~~~谢谢！！
最关键的应该不是追究责任，而是寻求根源，总结原因，避免重蹈覆辙吧？

P.S：这样的问题是比较少见，但要是RP不好的话，也会碰到的吧，有必要撤销这个部门了？没这么严重吧，呵呵……

leevon

原帖由 luoyear 于 2007-12-10 21:12 发表


当然，对于用户验收这样的活动，我们不仅要求系统测试时候去评估我们的测试覆盖率以及缺陷趋势，从而做出是否放行的决定。同时还要做好以下三件事情以确保用户验收测试的顺利通过：
1，必要的时候，能依据UAT C ...

谢谢，很不错阿，学习了~~~
重启程序重新演示，这个不错，是一个方法。
要求系统测试时候去评估我们的测试覆盖率以及缺陷趋势？测试覆盖率要如何评估？
还有，UAT Case跟Test Case是同一个概念么？
谢谢！

leevon

原帖由 云层 于 2007-12-11 17:06 发表
要明白在客户面前出现致命的问题影响很不好的不是道歉能搞定的，这个时候要灭杀证据！

很多演示活动中出了问题都可以这样解决，直接关电脑，然后找借口就行了！只要你动作快，用户不一定能反映出来是系统的问题。 ...

很好，直接重启电脑，然后找借口，这个方法很不错，绝对可以借鉴！
至于第二种方法，换一台系统正常的机器，万一不是系统的问题，而是我们软件问题，就不好办了，呵呵！
谢谢！

leevon

原帖由 czqiqi 于 2007-12-11 21:56 发表
既然发生了问题，那就说明你的软件确实存在某些漏出的BUG，如果只是想办法逃避的话，这些问题终究还是会暴露在用户面前的。最后的方法就是勇于承认错误，拿出你的诚意，拿出你的真诚来挽回你在客户心中的形象。过后， ...

勇于承认错误，用真诚来挽回公司在客户心中的形象！
谢谢！

puchonghui

这个还是要看实际情况
商场如战场
客户并不是在找什么知心朋友
很多时候不是一句道歉可以挽回的

luoyear

要求系统测试时候去评估我们的测试覆盖率以及缺陷趋势？测试覆盖率要如何评估？
1,形式上的覆盖，也就是每个细化到一定程度的需求必须要有1个正向的和一个反向的case去覆盖；
2，抽样检查：检查那些第一轮系统测试后，缺陷比较多的模块，抽样一些需求，看看真正用来测试这些需求的testcase够不够。
3，缺陷趋势方面，一方面可以参考自己公司的历史项目的缺陷分布模型，做个比对，另外一方面，就是发布前的最后1-2个星期，版本需要具备一定的稳定性。具体什么叫稳定，需要自己根据具体情况提出一个目标，如最后一周不能出现高等级的bug，每天发现的缺陷不能少于2个等。

还有，UAT Case跟Test Case是同一个概念么？
UAT case是客户从实际使用的角度提出的用例。比较象我们内部设计的End to End测试用例。

谢谢！ [/quote]

z_511

看到各位高手的见解，自知需要学习的还很多，进入测试行业不久，虚心来此学习