描述一个bug的故事

上周末,家,轩轩突然郑重其事地来找我。

 

轩轩:妈妈,我有个问题想要问下你。

 

我有点惊奇:什么问题?

 

轩轩:我发现了“英雄联盟”的一个bug,有什么途径提交给他们吗?

 

我思考了一下:额。。。,一般程序里会有一个“联系我们”之类的东西。。。,不过,这个好像不是为了反馈bug用的。嗯。。。也许你可以发布到微博上,然后@英雄联盟,有可能会收到回应。

 

轩轩:在微博上发表,是否所有人都会看到?怎么发呢?

 

我:(看来轩轩很重视这个bug,也许可以练习点什么)理论是上的。不过,在你提交bug之前,首先要确保你非常准确地描述了这个bug。这是个什么bug呢?

 

轩轩:#%&()——*&%#@%*()(@#%。。。

 

我(¤6¤??):不如这样,你先用电脑尽可能详细地描述一下这个bug

 

 

几分钟后,轩轩信心满满地叫我去看他描述的bug:“我已经写得很清楚了”。看得出来他已经非常用心地在描述bug了,一共写了两段话,可惜我当时没有保存下来,大体意思是:“某天我在英雄联盟训练营模式下发现了一个bug,这个bug也不是很严重,当我。。。。的时候,发现。。。。,然后。。。”竟然还可以用讲故事的口吻叙述一个bug,我以前从来没有想过!虽然这很有趣,我还不得不用专业的态度来纠正他的描述。

 

我:某天?是哪天?什么时候?我们得用尽可能准确的词语来描述,不能用这样模棱两可的词汇。你究竟是什么时候发现的这个bug的,在什么样的环境上发现的,最好都明确地写下来。其次,“这个bug也不是很严重”,这是你个人主观的判断,也许这个看起来不那么严重的bug会关联到其他的地方而引起严重的问题,所以你只要客观地描述你看到的现象就好了,去掉所有主观色彩的词汇。

 

轩轩:哦,那我改一下。

 

我:等等,你可以按照这样的思路来改,也许会描述的更清晰些。

   GIVEN   给定什么样的条件下,

   WHEN   当你做了什么的操作,

   THEN    系统会有什么样的反应,

   CAUSING 从而引起什么样的后果。

 

几分钟后,轩轩:妈妈,这个THEN的部分,我不大确定了,我可以再测试一下吗?

 

我:当然可以,如果你描述bug的时候发现任何你还不确定的东西,都可以停下来,重新去测试一下的。

 

于是轩轩,打开了游戏,开始了针对这个bugfollow up testing。测试了半个多小时,他有点沮丧地跑过来说:“也许没有必要提交这个bug了,它没有我原先以为的那么严重,只是针对一个英雄在一个场景下使用,会有点问题。”

 

我:真的是这样吗?我们一起来看看这个bug吧。

 

接下来我们大概又花了半个多小时,一起讨论这个bugGIVEN-WHEN-THEN-CAUSING的每个部分,作为对网游外行的我也终于搞清楚了这个bug究竟是什么。

 


 

正当我们两个都对截止目前的工作感觉比较满意的时候,戏剧性的转折点出现了。

 

起因是,轩轩决定在Causing里面增加一句话“理论上此时召唤师技能是进入3秒的CD的,但是如果你使用可以减少召唤师技能CD的技能或者模式,就可以达到落地之前使用召唤师技能。”,这段话貌似不是在描述这个bug的影响,所以我建议不能放到CAUSING里面,轩轩说他只是想告诉别人为什么会出现这个bug。“哦?你知道bug出现的原因?那太好了,我们可以把它放到DUETO里面”。于是,描述变成了这样:


 

可是,当我仔细思考这段话,感觉它描述的是WHEN的部分,不能算作真正的“原因”,可是就这点,没有能说服轩轩继续思考下去,他已经被我“折磨”得不耐烦了:“本来就是很清楚的一个事情,两句话就能说明白,你非得要用这么复杂的句式来写,设计师看到这个bug描述也被你搞晕了!

 

这句话实在有些出乎我意料,我以为提出“GIVEN-WHEN-DUETO-THEN-CAUSING”这样一个Bug描述的Pattern,可以帮助提交bug的人和修改bug的人理清自己的思路、更清晰更全面地认识bug,怎么反而起到适得其反的效果呢?

 

轩轩作为一个初中生,花费了2个多小时“折腾”一个bug,这本身已经很难得了,也许这样复杂的bug描述会让孩子难以接受?如果是这个原因,尚可。

不过,我非常想知道开发人员看到这样的bug描述会有什么样的感受?

 

如果您是、或者您认识“英雄联盟”的游戏开发者,有劳转发一下这个bug给他们吧,我很乐意听取来自开发者的任何反馈。


Comment Box is loading comments...