最近手上碰到一个烫手的
bug.
Bug History:
公司的Professional Service部门的同事报了一个bug。系统中有一个小的功能叫Rounding，可以对系统中某个模块内的Money类型的字段设置Round(hundredths, tenths,ones,tens,hundreds,thousands,millions)。 但是这个Rounding的功能并不work.
在上一个版本中， 开发分析下来fix的风险较大，涉及交广，牵涉很多逻辑，所以这个bug就被defferd。到这个版本再修。
但是在这个版本中，开发说能修好，所以开发老大就把这个bug放出来了。
验证Bug的坎坷经历：
我是负责重现和
验证这个bug的
测试员。经过和开发多次讨论下来，发现修复这个bug需要和Product Manager确认很多涉及到的逻辑。于是我就把收集的疑问整理后一并邮件发给美国的PM。当然这中间包括PM，开发和我的多次邮件往来确认相关逻辑和需求。 这里可能需要声明的是，我们公司的项目的product manager都在美国， 中国这边都是底层干活的测试，开发和DBA。所以遇到一些需要上层拿主意的事情都是要发邮件问的。
逻辑基本确认好了以后，就是开发和DBA改代码和usp了。在这期间，我测这个bug几乎是要把整个模块的都测一遍，因为这个模块的都是围绕这个这些字段的计算而作用的。这就是我和开发的痛苦煎熬的漫长过程。
每天都要花大量的时间在验证这个bug上面，然而每天验完后我都会告诉开发发现几个问题需要重新改。开发可能花一天或两天的时间来修改。第二天我再验证的时候，出于某种原因也是基本上花大量的时间把模块统测一遍， 不幸的是又有新的问题了。依旧打回去再改。如此往复一段时间后，我真是身心疲惫， 要知道每次验证都是要配新的数据。
由于这个bug是个low priority and high risk的妖孽bug, 加上release日期将近，我们决定在尽可能不影响系统的情况下先修复部分。而事实上这个bug已经在一定程度上算作一个不小的feature了（因为当初根本就没有做！）。截止小编发稿时，此bug还在抢救中！
惨痛的教训：
在这里呢，小编不想吐槽PM的的回复（我们把PM的回复供奉成spec）有多粗糙， 也不想吐槽开发的代码能力，就想自我反省一下小编在整件事情处理过程中的失败点（没总结出成功点）。当然这里总结的经验只是针对小编的公司的管理模式而言的。
首先， 小编将bug提交给开发的时候没有做充足并且完整的research。什么意思呢？还是以Rounding为例， 1）reseach模块中或系统中有多少地方可以设置？2）具体会作用于哪些字段？最好把field names列出来，以便验证时不会遗漏。 3）对每个字段进行非设置rounding的操作，去看下update后的值是否还有效。 4）每种Rounding对每个字段的作用的效果是怎样的。
其次，中途遇到逻辑不清的地方，需要PM发邮件问问题时，应该将问题都整理好。这里一份邮件中问题不要太多，也不要太少，3到4最好。 如果遇到比较复杂的问题，PM回答以后还是需要继续讨论，最好另起一封信的邮件专属讨论。所有邮件往来都要CC给所有可能参与到其中的人，开发和测试老大肯定少不了，不管他们care不care这个bug, 都得让他们之情。
最后，开发修改后轮到测试验证，这是得慎之又慎。像这类的bug, 如果开发第一次第二次改完后仍有大量隐患存在，就不仅仅是fail的事了，与开发验证交涉，最好是能提child bugs来修复。原来的bug作为parent bug对待，等所有child bugs都pass了，再将parent bug给pass掉。由于公司的‘潜规则’，一般bug没修好，我们都不直接fail，而是和开发先打个招呼，让他们私下修改，然后再pass掉。对于一般UI的bug可以这样做，但是像小编说的这个bug就不能这么做了，因为连rollback都不可能了。
小编吐槽的已经太多了，但是还没发泄完。如果大家有什么好建议给小编的，希望不吝赐教。因为小编经常处理麻烦事。
