软件开发和测试项目中，具有大量的信息可以作为软件测试计划的依据。如果仅考虑个别的信息来源，则可能造成测试的偏差。比如有些项目面临着巨大的成本或资源压力。在这样的压力下，缺乏经验的测试管理者，往往容易被压力蒙蔽，仅仅从成本出发，尽量压缩测试的范围，导致测试覆盖不够充分。有些测试投入充足的项目，因为无需考虑测试成本问题，可能导致过度测试的倾向。比如测试团队在多轮测试中，由于经费充足，可以尝试各种测试工具、方法和技术，并且能不断地挖掘出系统深处的缺陷，不断地报告缺陷并要求开发修复后才能发布，产品发布的时间被反复拖延、推迟，最终导码产品上市过晚，竞品已经占据市场的结果。

测试理论与实践的差异在于理论是具体实践的抽象，排除了实践中不可避免的各种压力、限制、认知偏见和信息不对称。由于实践中信息来源纷繁复杂，还有着各种压力和困难，所以很容易造成在项目中，难以对诸多要素进行综合的思考和平衡。所以，需要一个更能体现软件质量本质、更能综合各方面要素实质的概念来简化思考。

测试计划除了作为测试活动的安排和指导以外，还是个重要的沟通载体。 测试计划包含的信息应该能被其他利益相关方理解。而测试团队外部的利益相关方可能不像测试团队负责人那样对测试有着深刻的认识，并且他们也不关心测试活动的种种细节。所以，在测试计划中，测试计划和策略一定要以其他利益相关方能够理解的内容和概念出发。

在业界长期的测试实践中，测试专家和管理人员逐渐认识到，能体现测试本质并容易被其他利益相关方所理解的概念只有一个，即“风险”的概念。风险是当前未发生而未来有可能会发生并造成定负面影响的事件。软件测试是通过各种测试活动来发现软件或服务中是否存在引起风险的缺陷，并反馈风险信息给开发团队，由开发团队修复缺陷从而降低风险的活动。并且，软件测试活动中未发现缺陷则在一定程度上证明风险发生的概率很低，从而给软件的发布上线提供决策信息。功能和非功能(质量特性)的质量最终体现在产品或服务的风险上。比如，功能缺失或不可用，将导致产品质量风险的发生。产品容错程度不足、异常情况处理不足导致的产品失效、崩溃等情况，同样导致产品质量风险的发生。产品界面设计不够友好、用户体验不佳导致用户数量减少，也是产品的质量风险。

软件开发过程中的各种技术问题、资源问题、管理问题也体现在产品开发过程的风险上。比如，软件开发的过程管理问题造成的需求分析不足、开发返工，则可能导致开发费用过大的风险。架构设计考虑不够充分，存在扩展或移植的困难，则可能导致产品开发延期的风险。

风险相比软件测试和开发的专业知识更容易被各方理解和接受。发现和缓解风险，能更好地完成测试任务，同时满足各方面的期望。减少风险符合项目利益相关方的自身利益，所以从风险角度分析和阐述软件测试的各项决定和安排更容易得到项目利益相关方的理解和认同。为了规避风险所提出的测试团队的技能、环境、设备等建设和提高的要求，也能够得到最大程度上的支持。因此应该围绕发现风险、缓解风险的目标来建设测试团队的能力，而非反过来由测试团队的能力来决定要处理产品的哪些风险。下图概括了从风险出发进行分析能产生的效果。

从产品的风险出发可以分解到各种质量相关的风险，从而将软件质量具体化，将缦解风险所需要的各项资源明确化、量化，最后根据风险和缓解措施所需要的测试能力来设计对应的测试方案，这样能够对各方面的要求达成最佳的平衡。最后需要强调的一点是测试策略和测试计划的制订本质上与制订商业计划、做职业计划等工作一样，第一是面对不确定性，第二是面对有限资源，第三都是试图做出当前时间点上的最佳决策。测试计划和策略安排都应随实际情况的变化而不断地进行调整。即当通过测试发现原来预计大概率会发生的风险，由于开发团队的努力，变得不太可能发生了，这样的情况下，可以选择停止测试或者将测试资源投入到其他的风险上去。​