早上代码走查大家发现了不少问题，积极思考积极讨论，能够坚持把一件看似简单的事情很执着的坚持到底，一定会有收获。上次Bob说起，达芬奇的了不起，而当时我脑子里能想起来的就是他画鸡蛋的故事，能把一件事情刻意、反复做到极致的人，身上具备的这种特制，会带给他更多的收益。
最近两位团队QA让我越来越刮目相看，从昨天的MFQ到今天QA写用例时考虑到的波及范围的分析，都能考虑到很多从BA和DEV考虑不的点，彻底改变了之前，QA测试完全被开发牵着鼻子走，被动接受的局面。
现在回头想想这两种场景特别有趣:
场景一:曾经团队QA不愿意写测试用例，让开发去写，虽然节约了他们的一部分工作量，却可以从后面故障复盘中看出来，这样的用例因为视角缺失而带来的很多用例场景覆盖不全，或波及范围分析不够，导致频繁出现故障，外场问题，补丁修复，故障复盘等问题。从长远来看，这样的“节约时间”其实并不划算。
场景二:开发代码没有写完，测试用例根本写不出来。其实有两个主要原因:
1、写测试用例是从开发编码的视角去写，而不是从用户使用的角度去写。
2、前期需求分析不够，尤其是需求场景和AC写得不够。太多不确定性没有在需求分析阶段充分讨论澄清，而留给了后面编码和测试的阶段。这样做对后面编码和测试人员的经验要求非常高，而且导致需求无法按时按质完成的风险也极大。
引入MFQ和需求实例化等实践后，就会驱动BA和QA在一开始去细化需求场景和AC。把尽可能多的不确定性消除，这样QA对整个需求也很清楚了，自然也很容易从用户使用的角度同步甚至提前把测试用例准备好。而且这样的用例相对于之前拍脑袋想出来的经验更加全面。
做到上述几点，还差一个很重要的环节:频繁沟通，频繁反馈。
反馈环一、团队从去年开始做的一个尝试，会把AC和需求方案提前和领域PO，甚至售后和用户去确认，这样作为需求进入团队后第一个反馈环，尽早从客户那里拿到反馈，为了留有余量，这就要求我们尽可能更提前的去沟通和确认，这样可以更加安全的规避风险。
反馈环二、对于维护多年的系统，由于功能已经非常复杂，所以即使前期做了很多分析工作，依然可能存在一些漏考虑到的点。而在开发过程中，直接面对代码，就有可能会发现更多的信息。这个过程中，比如，我们识别出来的变更和风险点能尽早尽快和客户沟通确认，就能将解决问题的成本尽可能的减少。
综上所述，在新需求开发过程中，要想提高质量，开发出更满足用户要求的功能，需要团队的各种角色通力协作，从不同角度去把好质量关，而不管哪一个环节，最重要的就是，尽可能多、早、频繁的和客户去沟通，消除已经识别出来的隐患和不确定性。
