Automation Rate永远是软件测试经理或者Team Lead的痛。 每个在位的测试经理能想到的，和别人谈的最多的，就是怎么把Automation Rate提上去。 道理很简单，Automation Rate提高了，不但可以减小测试team在回归测试时的effort， 同时这也是一个Measurable的指标，是衡量一个team成熟度以及是否efficient的一个“重要”的标准。

然而Automation Rate永远不是那么容易提高的。一方面，国内的软件开发流程规范的很少，对于一些时间很紧的项目来讲，开发人员不愿意写设计文档。另外一方面，软件测试人员自身的素质有待提高，现在国内一般的情况是，员工通过面试，发现达不到开发的标准，还能被招进公司做测试人员。最后，在项目紧的情况下，如果有专门为Automation预留了时间，项目经理为了准时release，第一个砍掉的项目活动就是Automation.

在这种情况下，可谓是内忧外患。如果测试经理或者lead不够成熟，把Automation想成是用几个工具就可以达到的目标，那项目的automation测试基本上就是一项不可能完成的目标。

首先，测试经理或者lead要意识到，automation是为了提高测试团队的效率，保证回归测试的质量，提高项目release是整个项目组的信心，同时automation smoke test的case可以保证daily build的有效性。

其次，要做automation，需要有其他的基础。这个包括：

• 是否有专门的test case管理工具？测试的结果如何输入？测试经理或lead如何做monitor？
• 项目的test case是否完整？是否有效？如果有专门的测试开发人员，是否仅仅考查看case和看设计文档就能实现case的automation？
  
• 实现Automation的人员（可以是part time或者dedicate的人员）是否对需要automation的test case有足够的理解？如果没有，那说明还没有准备好开始做automation。
• 是否选择了有效的工具，很多人都用的工具不一定适合你，对于automation，轻量级的工具我个人更prefer，如果automation的人员有足够的知识，请专门花一点时间做programming。开始为了实现automation可以选择robot，QTP，Autoit等工具，但是做久了就会发现其实工具这个东西，运用之妙，存乎一心，测试人员永远不要为工具所限制，而是尽量把适合的工具用在适合的地方。
• 是否需要通用的automation框架。现在框架很多，STAF，RRAFS，关键是这个框架是否适合你的项目？

再次，是否能够让项目经理同意为automation预留resource和时间，这个对于测试经理来说相当关键。如果没有，那测试人员只能牺牲休息时间来做automation，对项目士气影响很大。

然后，如果决定开始做，automation绝对不是一个人的事情，做的人同样需要有design，需要team内部进行讨论这个方案的可行性。automation程序如何设计才能应对开发的设计变更？这些都需要考虑。

最后，automation的成果能否有效被保留？是否能有效的和daily build相集成？是否有使用说明书？是否有设计文档？测试team是否有自己的版本控制工具？是否有专人进行维护？这些都是automation程序开发人员需要考虑的事情。

如果不做automation，其实世界照样转。 如果你能用开发automation的时间发现更多有价值的bug，使release出去的软件quality更好，其实这样的QA/QC engineer更有价值。