Maven: 这是团队太注重自动化的一个普遍问题。
Motley: 什么意思？自动化测试是一件好事。它让我们在没有定期人工干预的情况下重新运行测试。如果没有自动化测试，每次在做出改变的时候我们就破坏产品的其他方面的风险。
Maven: 别误会我，自动化可以很棒。单元测试是自动化测试和我们一直在讨论的每个软件开发人员必须做的事情的形式。你改变，你运行你的测试，也许为确保你没有破坏任何功能而让其他的团队测试。越多单元测试越好。那些代码覆盖率较高的单元测试效果更佳。
Motley: 你在自相矛盾Maven先生。首先，你说你们太注重自动化，现在你又说越多越好。我很好奇想知道 - 到底哪个好？
Maven: 更多的单元测试 - 更好。更多基于场景的自动化测试 - 不一定好。为产品的核心用户场景设计测试集是非常有价值的.然而，在情景水平下过分依赖自动化是有缺点的：
如果测试基础结构的架构非常脆弱（即健壮性不足），当每次产品变化，自动化测试可能需要跟着大幅度变化。测试人员会花更多的时间试图让自动化测试工作而不是增加产品的实际价值。
重点关注自动化测试会导致测试团队总是落在开发团队之后，如果这是你如何组织你的团队的话。如果开发人员如他们应该做的那样对可测试性进行设计，这种情况就不是问题，因为测试人员可以开始很快地开发自动化测试。如果自动化是开发之后考虑的事情，开发人员或许会在测试团队测试完成之前开始开发下一个功能，之前的功能按照我们的定义来说并未完成。由于代码不再新鲜，之后再返回进行诊断和调试问题还是一次昂贵的上下文切换。
如果目前建立的基础设施预计在下一版本中改变的话，自动化测试往往必需改写。如果自动化的基础设施不久就要改变，团队应该花大量时间来构建它吗？困难的要求。
即使你注入一些随机性测试，自动化测试也不能像用户一样思考。过度依赖自动化可能会造成一些只有发布后才能发现的烦人的产品测试漏洞。
Motley: 在这，我想自动化一直走下去总会更好。但你确实提出了一些好观点。我会和测试人员谈谈，并保证我们关注的事情是正确的。如果这意味着我们更快的发行产品，并且没有给自己造成任何长期的危害的话，我们应该放弃一些自动化测试。
Maven: 听起来不错。让我知道你是怎么做的。多亏了你，现在我要拿些棉纸堵住我的鼻子来止血。
Motley: 哈！你知道你活该。
______________________________
Maven的观点: 在微软，比起自动化切实改善的流程，我（James）和测试团队似乎要花更长的时间来诊断和排查组织范围内的自动化基础设施，在测试计划中与开发人员紧密合作，并像用户一样手动测试产品。自动化是一种在开发中较早检测回归的工具，但它不该被当成支柱。鉴于这一理念，限制了你们耗在自动化上的时间使之合理，并注意收益递减。
Maven的两个间接观点: 我们谈到了过去的代码覆盖率。测试团队犯的一个错误是他们要求他们自己的代码覆盖率数值，而且覆盖的范围该针对自动化测试衡量。基于场景的自动化测试不仅是测试各个组件，模块，模式和代码行 - 它更多的是确保一个场景如它应该的一样运行。放弃代码覆盖率度量去关注开发人员，并用单元测试测量。
Maven的资源:
I.M. Testy的博客——一个微软工程卓越已经教测试很久的人
Alan Page的注释和随笔——另一个工程卓越中真正了解他测试资料的人
在微软我们如何测试软件，Page，Johnston和Rollison, 微软出版社, ISBN: 9780735624252, 2008.8
{测试窝原创译文，译者：非辑}
译者简介：非辑，中山大学本科在读，研究信息描述，数据整合
