通常BV已经存在，测试人员\测试主管需要了解已经存在的BV，而不是去创造新的BV或者修改已有的BV，除非是在BrainStorm阶段。BV也是最case-by-case的，没有一定之规，以下所列的是一些常见的BV：
·满足客户需求：如果一项软件开发任务直接或者间接的来源于客户需求，（换句话说就是有人拿钱等着买这个软件，或者已经付了钱等着拿软件），而且开价又足够大，那么满足客户需求就成为BV。客户又可以分为定制客户和市场客户：定制客户通常是大公司、大客户，需求来自客户本身；市场客户通常是普通用户，数量庞大，不可能直接一一沟通，需求来自针对客户的市场调研。通常这样BV所指明的工作方向是很容易把握的，就是客户要什么就做什么，优先级也很容易设定，那就是——问客户。难点仅存在于有效持续的沟通和DCR（DesignChangeRequirement）的控制。
·战略合作需求：某种意义上说来自战略合作伙伴的需求也是一种定制客户需求，不同之处在于战略合作伙伴既是你的客户也是最终用户的生产者。例如，Dell对于Microsoft来说就是战略合作伙伴，如果Dell要求将其使用的几款显卡驱动放入新款Windows的缺省显卡驱动列表中，那么这就是一个战略合作需求，因为帮助Dell就是帮助Microsoft自己，Dell每卖出一台PC都要向Microsoft支付使用费，Dell卖得越好Microsoft就盈利越多。然而对于最终用户而言，Dell和Microsoft又都是生产者。对于这样的BV，确定工作方向将变得复杂，因为事实上有两个方向，一个是最终用户的需求，另一个是战略合作伙伴的需求，而且在双方没有达成战略共识并且沟通不畅的情况下，通常这两个工作方向不同。测试人员\测试主管不能接受的情况是两个方向是矛盾的、不相容的，当然最糟糕的情况是南辕北辙。例如，合作伙伴需要增加某一功能，并且该功能预期会带来性能下降，而最终用户希望提高性能。在这种情况下只能通过沟通消除矛盾，如果其在项目开始前不能解决，那么该项目将面临重大风险。优先级的设定也是一样，需要沟通。
·复制竞争对手的成功，蚕食市场份额：一般适用于大公司在后发领域中用于与对手竞争蚕食市场份额时使用。这种BV战略的灵魂就是“走别人的路，让别人无路可走”（出自小沈阳语录：））。Microsoft大量地使用了这种BV，比如在Xbox、WindowsMobilePhone、搜索引擎等产品上。这种BV有别于以上BV在于其强调产品与竞争对手产品相比：一，有哪些差距；二，哪里能做得比对手产品好。这时来自于客户的需求反而没有那么重要（注意，我不是说客户需求不重要）。对于测试人员必须首先熟悉竞争对手的产品，同时了解自身产品相对于竞争对手产品的差距，或者哪些地方能做得更好，然后根据这两点确定工作方向和设定优先级。
·辅助相关产品：一般适用于大公司，在一个产品线中某个或某些产品本身并不大赚钱，有时甚至是赔钱的，但是它的存在将有效增大产品线上其他产品的销售，或者保护了其他产品的现有市场份额。这样的BV较难把握，需要对整个产品线的各个产品、相互关系、客户需求和企业商业战略有全盘理解，然后确定工作方向和设定优先级。
·适应未来的技术趋势：一般适用于大公司，产品是为未来2~5年的市场准备的，在某种程度上是赌博，其前期投资很大而且没有或者很少的客户需求。比如现在的云计算、两年前的iPhone等等。这样的BV是最难把握的，因为基本没有客户需求可以供参考，工作方向很难确定，优先级设定则更加困难。
理解已有产品：
大多数情况下测试人员\测试主管所面对的产品不是VersionOne的产品，即项目将在已有产品上展开，那么对已有产品的理解就十分重要。测试是要保证N+1的所有功能（N个是已有产品的功能，1是新加功能）都正常工作，而不仅仅是保证新加功能正常。通常，测试人员\测试主管需要了解：
·产品的功能以及各个产品的历史；
·使用产品的典型客户和典型应用场景；
·产品的特殊要求；
·法律对于某些产品的特殊要求；
·当前产品的PainPoints；
·主要竞争对手产品、其优势和劣势。
理解产品的已有测试：
在对已有产品有所理解后，还应当理解已有产品的已有测试。针对已有测试的理解将有助于为新项目建立完善的测试体系，形成回归测试，是保证N部分功能在新版本中正常工作的重要手段；另外，已有测试中的TestInfrastructure是测试中可以重用的部分（TestInfrastructure就是除了TestCase以外的测试代码，包括TestHarness，TestManagementSystem等等）。其包括：
·功能测试；
·稳定性测试；
·性能测试；
·场景测试；
·TestInfrastructure。
