高高在上的用户

2010-08-12  饶乐 

今天看到一个有趣的事情,说的是一个测试团队发现了同一个选日期的功能在不同的模式下表现的行为有不一致,于是提交了bug给dev去fix,最后发布到生产环境。用户在使用之后反而不爽了,因为那个功能的十个模式中他们常用的只有一个,现在反倒把他们常用模式下的操作行为改了。故事得出一个结论:
“Don’t fix bugs unless users want them fixed”

A bug is something that bugs someone who matters.

Keep that in mind the next time your team starts fixing bugs the users haven’t complained about.
这可难为我们测试人员了,一直说要站在用户角度去分析,其实我们还是在我们的角度去揣测用户的喜好。真正的想用户之所想,还是得走到用户中间去。我们高高在上的用户啊,赐予我们慧眼吧!
294°/2826 人阅读/12 条评论 发表评论

张林  2010-08-12

先学会沟通,沟通也可以fix bug......


金鑫  2010-08-12

在易用性这块,的确有很多总结出来的东西(包括一些行业标准、标杆产品如windows操作风格等等诸如此类的标准)值得我们参考,网上也是随处可得。但这些是不是就真的达到最佳的用户体验呢?往往一个蹩脚的操作在用户的“习以为常”下视乎变得顺理成章。
同意一楼的观点,外加对用户使用习惯的引导。正所谓没有最好的,只有更合适的产品


刘志强  2010-08-12

用户的 需要千奇百怪 用户的水平参差不齐 。。


饶乐  2010-08-12

金鑫: 在易用性这块,的确有很多总结出来的东西(包括一些行业标准、标杆产品如windows操作风格等等诸如此类的标准)值得我们参考,网上也是随处可得。但这些是不是就真的达到
非常赞同


夏洁  2010-08-12

金鑫: 在易用性这块,的确有很多总结出来的东西(包括一些行业标准、标杆产品如windows操作风格等等诸如此类的标准)值得我们参考,网上也是随处可得。但这些是不是就真的达到
有关于易用性的文档吗?


李超  2010-08-12

我们发现BUG一般都会找客户确认,有些可能是必须修改的,有些如果不影响程序安全性一般由客户决定修改还是保留


金鑫  2010-08-12

夏洁: 有关于易用性的文档吗?
哈哈  最新我给部门内做了一个易用性测试用例设计的分享


夏洁  2010-08-12

金鑫: 哈哈  最新我给部门内做了一个易用性测试用例设计的分享


刘俊  2010-08-13

PM的事情,结论只会有一个,客户至上


吴小香  2010-08-13

呵呵……用户就是上帝!


刘玉晓  2010-08-14

其实,用户才是我们的老板。


楮迎春  2010-08-17

有时候用户的需求很奇怪


登录 后发表评论