昨天在我们一个数字化管理平台项目组微信群里讨论的一个问题,引起了我的反思。我在想为什么系统已经上线半年多了才暴露这个问题,是因为时间到了2024年吗?
首先是产品经理在群里问:“为啥现在XX例会模块23年月份被禁选了,导致23年的信息现在无法查看?”
紧接着研发负责人反馈:“这个你当时不是说历史月的数据不让点,我们特意禁了的。”
“你记错了吧,XX例会没有禁选需求,是要每个月份都能看的”产品经理再次说着。
“之前说的禁过,我都记着呢。要不然我们禁这干啥?”研发负责人反问着。
产品经理又说: “这是12月的截图,你看下代码,这咋能禁,23年12月看着都正常着呢。”
研发负责人接着说:“当时2023年有数据 2022年没数据,我记得你当时说是把上年的禁了。”
“是,但现在23年有数据,也被禁了,得打开对2023年的限制。”产品经理又说。
“那22年21年是不是也打开?”研发负责人反问了一下。
产品经理十分肯定的说:“不打开,23年之前都没数据还是保存禁选。”
问题讨论到这里告一段落了。事情的起因是,之前我们测试的时候发现XX例会模块21年22年没有客户数据,点击时提示信息不友好,于是产品经理就要求研发人员把21年和22年禁选。然后研发人员就理解成了,每一年都不能查看上年数据,每一年都禁选上年数据。半年前,OK的,因为还是2023年,这么处理没有问题。但现在到了2024年了,2023年本身有数据,却也被禁选了,客户反馈这就是一个线上bug了。
然后我们组长就问了我们这边的测试负责人,之前测试的时候没有考虑到2024年的测试场景吗?测试人员说:“没有,我们测试的时候是23年8月份,确实没想到2024年看不了数据的问题”。组长说:“好,那你们以后测试的时候需要考虑更多的时间场景,这次的这个问题就算是前车之鉴吧。”
在我看来,这个问题的出现比较有特殊性,从表面上看一方面是开发对代码的处理逻辑识别的不全面,另一方面测试人员也没有想到2024年看2023年数据的问题。
跳出表面,站在bug之上,我认为这是属于需求设计存在缺陷的问题。源头上从需求设计的时候就应该从正反两个方面去制定规则。2023年对之前没数据年份的处理逻辑是什么?2024及以后年对之前有数据年份的处理逻辑是什么?如果需求写到这么明确,我相信开发人员不会理解再有偏差,测试人员也能充分考虑到这个测试点。