week8

最近我的朋友很烦。我的朋友是一个测试经理，有一个5人的团队，以手工测试为主。新年过后，产品经理列出了一堆项目计划，明确规定了哪天上线哪些功能，上线的频率很高，每周都要上大功能，细细测的话，3个星期测完一个功能差不多吧。产品经理和项目经理很客气的争取研发的意见，这就郁闷了，说搞不定吧，是不是显得能力不强，还没干活就叫苦叫累，还得写理由为什么搞不定，提出建议，光写邮件就要写一天。说能搞定吧，那是骗自己的，还要安抚团队的小伙伴，暗暗盘算一下谁要呆不住另谋高就了。

测试这个活真的很有技巧，光懂技术是不行的。举一个例子，我和HR去面试，HR总会问一个问题，你和开发意见不统一，就差吵起来了，你怎么处理？这个题目没有标准答案，每每问到这题，我就细心观察应聘者的表情，很有意思。

说回到朋友的烦恼，我觉得短期想要完美解决真是太难了，要么忍要么撕。撕得过就撕，撕不过只能忍。长期来看，传统的测试工作甚至研发流程需要优化，来顺应快速的变化，让用户，产品，开发，项目经理，以及各种领导们满意。这里面有3个关键问题可以考虑：

第一，测试的程度。开发做不完没法造假，代码优美也好，烂也好，总之要拿出功能来。测试的灵活度很大，可以手工测，也可以写自动化测，更有大胆的人直接说测过了没问题其实根本没测。

第二，开发首次提交测试的质量。一旦开发同事说代码写完了部署到QA，测试组就开始测试了，有的开发真心做的很烂（理解开发也有苦衷），甚至功能是不完整的，到时候要交差，浑水摸鱼也是可能的，如果这个环节模糊不清的话，测试同事一般会很郁闷的，deadline就在哪里，bug关不掉，越接近上线时间压力就越大了。

第三，人们对好的质量理解是不一致的。一般来说，测试心中的合格质量标准会比较高，总想多测测，尽善尽美，无奈资源有限，各种争论和妥协也很正常。我们做质量工作的，客户满意才是标准。

因此，我觉得把三个问题协调好，大家理解一致，互相理解体谅，暂时可以度过难关。长期来看，开发和测试分属不同的团队，大家有不同的KPI，此题无解。下个星期继续写。