本文讲述了测试人员在面对复杂业务和缺乏文档的情况下，如何通过亲自实践、建立脑图来理解和掌握业务细节。作者强调了测试人员熟悉产品业务逻辑的重要性，以及他们在产品评审中的角色转变，从被动听者变为积极参与者和潜在的产品负责人。
有时一个边缘功能很久很久不改动，那再需要测通它时，经常需要对接多方，有的请假了有的调走了有的不清楚更甚者有时候一个功能找不到清楚的人.......
当没有可查阅的文档或记录，找不到完整的信息时，咋办？
当然是自己动手啊，作为测试，求助pm，产品，开发，运营，甚至......很大概率得不到明确的结果，anyway 总得自己试过了明确总结了，才能相信。昨天整理文档时发现的以前一份脑图：
当时是为了测一个预约提醒功能，但是涉及好几条业务，问了一圈没有一个明确说法，没有已知的文档记录。根据一点了解和他人提醒，一个个摸索尝试，平时再及时记录积累，形成自己的“脑图”。
我自己特别享受捋顺一团毛线，心里有数下次不慌的安心。梳理完的脑图，被开发产品各要走了一份。
当时那份工作让我又爱又恨，不止做测试，还要和产品轮班做一些技术支持的值班工作。
客服欸，下班有人call，周末有人叫，出了电影院第一时间就是打开手机看群里有没有人反馈问题。
但也是这样一份工作，给了我一个很大的冲击提醒：我必须充分清楚业务及交叉业务的每一个细节，才能第一时间给出解决办法，不误导用户。
也是这种意识，让我在“测完这个项目”之余，摸索每一个细节，去梳理分享。
做测试，我们更要足够熟悉自己的产品：
熟知已有的业务逻辑，能在产品提出新的变更时及时判断出是否存在冲突及风险
在TD评审、产品评审时，不再是一个倾听的与会者
不止做测试，做产品，做pm，做产品的“负责人”
当我们跳出“测试”，我们能做的比自己想的多很多......
1453
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
