一、从一个 Bug 说起

最近在使用一个 IM 时,突然发现一个有趣的秘密。

话说这个 IM 有一个发起问卷的功能,这个功能支持匿名答卷,效果图如下:

有一次在使用时,我好奇的点了点几个入口,突然发现匿名的内容和实名确认名单,可以通过时间线进行关联,我简直惊呆了。

到底怎么关联的呢?别着急,听我慢慢说。

上图中应该能看到发起问卷的时间是 3/14 21:38,记好这个时间,我们再打开确认人列表如下图:

从图中可以看到每个人确认后面(前面被打码掉的是实名的确认人信息),会有一个确认时间的记录,这个记录中左边是用户实名,右边是时间线。

接着我们返回到第一个图的问卷主页,点击问卷中某个问题的回答,会打开新的问卷结果查看页面,如下图:

看到没?每个匿名回答后面也有个时间,这个时间减去问卷发起的时间,恰好等于实名确认记录页面那个时间线(并且,它已经给做好了排序,实名确认记录的顺序和回答的顺序刚好相反,然后就完全一一对应了)。

我的天,原来这个匿名只是把实名和回答放到两个页面显示而已,吓得我一身汗。

二、我想说什么

今天不讨论这个 bug 的发现和定位,我想继续说说需求的合理性验证。

需求相关的话题,我之前有写过三篇文章了,可以点击如下链接回顾:
《测试人员参与需求评审的价值是什么》
《需求评审之实战演练》
《需求评审之隐性需求》

其中在第二篇文章中,我有提到测试人员在需求评审过程中,应该考虑需求的合理性。

按理说这种事情应该是产品来考虑的,但经常会发现产品对产品使用的路径考虑的没有测试周全。

比如上面这个例子,如果从每个功能单独来看,什么毛病都没有,说不定当时还测试出时间线显示不准确的问题呢。

但是把三个时间点一结合,就出现问题了,而这个问题又不是功能性问题,只是没有达到需求预期的「匿名问卷」的效果,所以这个效果应该也是我们一个重要的测试点。

如果是在需求评审阶段,评审合理性的时候就需要考虑设计是否满足了需求,如果是在测试阶段,就需要优先验证是否满足了需求的最终效果,而不是只是验证功能实现了正确的结果。

三、我们怎么做

其实谁也不希望出问题,但是真出现了问题也还是很无奈,比如上面这个例子,现在这个现状就是,之前做的那么多铺垫全白费了,满足了表面上的需求,却没有实现真正需要的需求,而且使用者可能都以为是真正的匿名呢,反而会造成一些使用上的隐患。

如果要规避这种问题,产品经理考虑问题的角度当然是需要更周全,特别是提供的设计方案稿,不能仅仅是满足了表面需求,但是说起来容易,做起来难呀。

如果是从测试角度看的话,我们需要固化测试人员对需求的关注度,同时要时刻记住需求合理性需求全面性这两个关注点,时刻从这两个角度进行需求确认,只有这两个角度都经过验证通过后,才开始真正的功能测试。

又或者说把这两点当作方法论一样去应用和实践,借助方法论从而更有目的的指导实践。

今天重新聊这个话题,是因为发现这样的 bug 真的很无语,就算功能测试做的再怎么天衣无缝,结果反而事与愿违,甚至悲哀。

以上,记录了一个发现的奇葩 bug,基于此,建议大家在项目过程中都要关注需求的合理性,从而尽可能早地避免问题,不知道你是否同意我的观点,欢迎留言说说你的意见。

当然,如果你觉得自己有所收获,欢迎分享文章到朋友圈 + 点个「在看」让更多人看到,谢谢。


↙↙↙阅读原文可查看相关链接,并与作者交流