一个解决方案中的所有非功能特性都是设计层特性，并且通常不能在迭代中演变。需要预先对其进行讨论，而且需要在解决方案确定时尽快讨论，是的……在解决方案设计确定时尽快讨论。如果这些特性在最开始没有被正确嵌入的话，那么它们最终永远都不会在测试中被找到。单元测试能做这些吗？当然不能！

　　“噢~~~，这就是为什么我们做验收测试驱动开发啊！”你说。我同意，但是我们往往并没有将ATDD做好，我们只关注客户所知道和所问的内容，而没有关注前期需要考虑和捕获的内容。

　　“那我们就只关注功能吧。”这是我经常听到的一句话，往往让我感到厌烦……这意味着很难想到其他的事情，我们只好继续前行，并祈祷它是对的。你是否“曾经”听过“忽略”敏捷呢？敏捷就是要从一开始就把事情做对。

　　测试通过静态测试从一开始就协助建立正确的解决方案。静态测试是“不通过执行代码来测试解决方案”。静态测试之美在于它可以在任何时间和任何地点执行。静态测试应该在解决方案的第一个想法产生时执行。理想情况下，应该有个测试人员提出这样的问题：“这是功能不错……但你是如何确定它是有价值的呢？”通过问题，图表和该解决方案的计划来测试该概念以查看它是否真正交付了所需要的解决方案，这是产品生命中至关重要的一部分。

　　我们还可以测试交付计划，关注风险、时间以及各组件间的依赖，以及如何利用不同等级的“完成”来证明我们正在往正确的解决方案行进。往“很好地完成”的方向上定义“完成”需要正确的人在工作初期就参与进来，而不是在编码已经开始之后。测试计划是至关重要的——是否定义了正确的环境、团队、资源和方法来交付价值？这是一个问题，但往往并没有在编码前得到回答。这个奇妙的新测试制度的存在引发了这个问题，并且所有人都在前往下一步之前就把它回答了。

　　测试计划的完成可以通过使用测试设计技术预先定义接受标准。你可能会喊道：“什么？？？已经开始测试了？？？”是的，完全正确。如果不提前执行的话，那测试人员获取的那些培训和证书又有什么意义呢？你看到测试人员所做的大部分测试执行活动都是他们基于风险和测试设计技术规范而形成的测试设计活动的结果。概念、特性、长篇故事和用户实例其实都只是规范在不同名字下的转译。更好地，在理想的敏捷世界里，测试人员会参与到需求定义中，这样他们就能够静态测试它们，然后可以在任何人试图实现一行代码前对其应用动态技术。

　　接下来，我们开始真正的工作（轻笑……任何人如果觉得编码前的工作不是工作的话，那他并没有理解工作的概念），我们开始编码，做单元测试，改进代码，做集成测试，将代码发布到测试环境（咚，咚，咚……鼓声响起）……我们开始尽全力寻找紧急行为！

　　紧急行为——这是测试人员在敏捷队伍中的真正价值：关注模块、代码和用户故事如何结合在一起从而交付所需要的功能。但是我们都知道这些地方往往是那些重要bug的藏身之处。bug只有在我们开始多方位查看解决方案时才会露出端倪。测试人员的技能就是在系统中根据客户需求和路径风险设计这些路径，利用测试技术定位需要关注的重要区域。这里是决策表和有限状态模型（比如：N-1切换覆盖）真正发挥作用的地方。那些在单元测试或集成测试时没被发现的缺陷，会让验收测试立即崩溃。

　　在系统测试过程中，设计测试发掘具有风险的紧急行为，提供具有实践经验的证明来评估覆盖率、遗留风险、缺陷密度、开发进度等其它质量属性也是测试人员应该具有的技能。当然我并不是说开发人员或BA不能做这些，只是他们太过忙于自己的工作，往往没有时间或精力去想这些。同样我建议测试理念和技巧在计划、执行和报告这些问题上是最有效和高效的。

　　这把我们带到了确认和验证的讨论。它们的不同点到底在哪里？验证是确保所建立的东西是正确的——符合标准，遵循模式，在正确的时间做正确的事情。确认在另一方面是定义正确的事情是什么！确认和验证这两个部分都必须完成，测试给了我们完成这两部分的技术和技能，同时也允许我们将这两部分覆盖到系统需要的各种属性上（例如质量）。