让需求理解也presention起来

之前在B公司，有很多的presention机会，新人自我介绍，试用期满答辩，职位晋升，工作产出评审，知识分享，专业培训等等。所以经过B公司正规历练的人，都有着一定的presention技能，哪怕一个很普通的技术人员。B公司为什么有这样的一个传统，我不深究了，只是我发现这个方法很好，被我应用到了测试管理工作中，尤其是需求理解度确认 以及 测试用例评审。

这里我想重点说的是需求理解度确认。

被要求上台做需求理解度presention的QA，pass的标志就是“讲的请，问不倒”。并不是赤手空拳上去接受霹雳啪啦的发问，而是会遵循一个基本流程。

• 先跟大家说明需求的业务背景概要--从业务应用上去理解需求；
• 然后用面向对象的方式描述业务主体流程，场景；
• 接着选择重点业务详细讲述，可以辅助UML图形，活动图，状态图，序列图，自由组合；
• 再后来讲述测试需求（含非功能测试需求）验收标准，测试策略，测试重点、难点。
• 最后就是接受集体轰炸。当然前面也可以适时轰炸。

Presention过程中可能会用到需求文档中的一些原始资料，但是我们还是极力鼓励原创，即消化吸收需求后，要用自己的语言文字表达出来。记得曾经有我们的小QA被底下的人轰炸到语塞甚至委屈到掉眼泪。比如说你问的这个需求上也没写清楚嘛，可是你不搞清楚，怎么测试呢？比如说“大概，也许是这样的吧”，可是这样的标准如何具备可测试性呢？......

如果真的能经受住这5轮考验的测试人员，那么他写的测试用例，他在测试过程中对问题轻重缓急的拿捏，我们都可以给予一定的信赖。且具备良好表达说服能力的人，在与开发人员沟通的时候我们也不必担忧了。真是一举N得！