测试是检验和确认。我们都知道，它需要2个V（verification&validation），来使测试完成。
然而，如果不对与静态测试相对应的动态测试是什么进行解释，那讨论就将是不完整的。动态测试是验证（validation），另一个V。动态测试就是你使用实际的系统（不是什么代表系统的工件或模型），提供输入，获得输出并与预期运行输出的进行比较。它是以发现错误为目的的在系统上实际动手检验的工作。
在这个过程中，我们将了解关于测试以下两种常见误解为何都是错误的：
1.测试是在最后才开始的工作
2.测试只需由测试人员来进行，和其他人无关
让我们先从一个关于V模型的快速参考开始：
在V模型的左侧是不由QA团队参与的活动。
在右侧，我们有一些由测试者和用户对开发团队采取的的处理。
让我们从——需求收集开始。它由业务分析人员和其他更高级别的管理部门执行——该阶段的输出文档是商业需求文档（Business requirement document），简称BRD。
下一个阶段是在系统设计。在系统设计阶段，业务需求被转化为功能需求，在功能需求文档中（FRD，Functional requirements document）。当转换过程中，开发团队（此步骤的主要实施者）会对BRD文件一步一步，一页一页，并且一行行的仔细检查。尽管主要目标是为了翻译业务需求，BRD文件仍会被轮流审查。
举个例子：假设这是银行网站的BRD，有很大的安全需求。在其BRD的一节中谈到了对各种用户在网银网站创建帐户密码的规则。期中的一个规则是：一个用户不能使用他在其他帐户使用过的密码。这是不可行的，因为，一个站点可以建议用户应该如何设置其登录信息，但是没办法对其进行强制。所以，这个要求是不可行的——换言之，无法通过软件来实现。
现在让我们在此例子基础上考虑以下几点：
怎么确定这个需求是无法构建的,所以也无法测试(换句话说,是不可行的)?我们是否先要有银行的网站,然后设置登录名和密码,最后才意识到这是不可能的?不,我们只是对这个BRD进行了审查，当然还需要一些常见的商业常识。
我们我们是否在对这个要求进行测试？是的，但纯粹基于理论，概念意义上而不是实际通过AUT（测试应用）。
这是此试验的物理形式？——对BRD的简单的阅读，或正是审查BRD，或更正式的可行性分析报告。
