Risk and RBT(风险及基于需求的测试)

  I think we need to break out of the mythology that testing is some kind of robotic process.
我想我们需要粉碎这种测试观点:测试是一种机械的过程.
 
需求开发不是在项目启动时一次搞定的。实际上，需求是贯穿在项目生命周期中的两方谈判。一方在问：我们需要什么？而另一方则在问：我们能构建什么？
 
这两方对话的质量帮助决定产品的最终质量。
 
我把需求理解成众多想法的集合，它们共同为特定产品定义质量。我把测试定义成开发一套评估系统的过程，用于对产品质量进行评估。
 
RISK AND REQUIREMENTS TESTING 风险与需求测试
至少有四种关于需求与测试的腐朽观点：
1.除非有稳定的需求，否则测试不可能进行。
2.一个软件产品必须满足它的特定的需求。
3.所有测试用例必须可追踪到一个或多个特定的需求项，反之亦然。
4.需求必须以可测的方式描述。
 
然而，当我们考虑到风险，我相信有更丰富的概念出现。
 
Testing without stated requirements 没有特定需求下的测试
满足需求是非常重要的，测试员的工作之一就是确认产品满足需求，所以明显测试人员需要清楚需求。所以上面说的不无道理，并且在大部分情况下是对的。
 
但是，由于不完整性和不清晰性，测试不能仅仅认为是一个确认过程。测试同时还是探索需求和实现的过程。因此，测试不仅可以没有特定需求，而且在需求不确定的情况下特别有用。我想我们需要粉碎这种测试观点:测试是一种机械的过程.通过测试和开发的合作会产生巨大的价值。有经验的测试员通过他们对未定需求的理解评价产品，并且通过观察来挑战或提问项目成员对质量的共同理解。
 
一个好的测试员会对特定需求的差距始终保持警惕，并且解决这些差距到一定的程度：满足特定情况下的风险。
 
Satisfying stated requirements 满足特定需求
如果每一个特定的需求项都是产品的真实声明，然后我们把产品质量定义为这一前提的延伸。那么软件产品必须满足它的特定需求这一观点是成立的。但是那有赖于我们有非常清晰和完整的需求集合。否则，你将被锁定在一个很窄的质量范围内。
 
关于满足需求的更广泛的思考范围是把我们的思维转变到考虑不满足特定需求的风险。好的测试员会努力地回答这个问题：什么是这个产品的重要问题？
 
Tracing test cases to requirements 把测试用例跟踪到需求
需求如果要发挥作用，则测试与需求之间应该有所关联。谈到可追踪性，通常摘要为：
为每个需求项ID，列举关联的测试用例的ID；为每个测试ID，列举关联的需求ID。
测试的完整性被大概地通过“对于每个需求项，至少有一个测试关联”来估计。这是一个很理想的观点。
如果可追踪性的目的是用于证明测试策略已经验证了产品的需求，那么我们应该进一步。我们应该随时准备回答客户的问题。“你怎么知道它证明了？”我们应该能解释我们的测试与需求之间的关系。重要的是需求和测试是如何关联的，并且随着产品风险越高越重要。
 
Stating requirements in testable terms 在可测性方面衡量需求
需求有意义是非常重要的。然而，“可测性”通常定义为“有利于完全可靠，一致性和可观测性的度量，从而决定是否顺从需求”。这个观点强调除非我们能够度量是否成功，否则我们永远不能知道我们是否完成测试。
 
首先我们应该重新认识一下测试员，他们不是懒汉，他们拥有普通人的洞察能力和推理能力。一个典型的测试员应该能够探索需求的含义和潜在意义，而不一定需要这些信息，就像一个濒临绝种的小秃鹰被滴入眼药水一样。事实上，尝试通过简化需求说明从而达到可测试程度，进而减少测试人员的麻烦，这种做法有可能造成更大的麻烦。
 
看一下一个真实的例子：显示控制器应该在300毫秒内响应用户的输入。
当一名测试员看到这个需求的时候，他以为要买一台特定的仪器来测量产品的毫秒级性能。后来他意识到：一个正常人能辨别正负50毫秒的分辨率，也许这已经足够精确了。再后来他意识到：也许这个需求项指定到毫秒级不是为了使需求更有意义，而是为了使需求更具衡量性。当他问到设计者时，发现真正的需求是：响应时间“在这个版本的产品中不要慢得烦人”。
 
因此我们看到实际的测试不一定需要精确的需求说明，测试是通过有效的和有意义的沟通进行的。
 
REQUIREMENTS, TESTING,AND CHALLENGING SOFTWARE 需求，测试与挑战软件
1.我们认识产品的问题的能力是受限于我们对问题可能产生的地方的理解。需求规格说明书是一个问题信息的潜在来源。
 
2.我们招致风险取决于发布产品中包含的重要问题的程度和范围。测试的真正任务是把这些风险暴露出来。而不仅仅是展现特定需求的不一致性。
 
3.特别是在高风险的情况下，如果我们能证明测试策略与定义的质量之间的关联，测试过程应该会更具说服力。这超出了至少一个测试对应一个需求项的范畴。
 
4.如果需求说明更多地关注什么才是关键的要求，关注风险、益处和每个需求项的重要程度，则测试过程会更有效。目标可度量性在某些情况下是需要的，但是它不足以产生健壮的测试。
 
如果把这些规则应用到高风险或复杂的软件会发生什么事情呢？
随着风险和复杂度的增加，如果测试过程要想完成任务，测试参与到需求的对话中就显得尤为重要了。需要更多的测试技巧，作为与开发更好的配合，与用户更好的沟通。在这个关于我们要什么的对话中，测试员应该寻找沟通的更多渠道：更多文档的原材料，图表，演示，谈话和用例。在关于我们能构建什么的对话中，测试员应该熟悉采用了什么技术，并且与开发人员一起为产品构建可增强可测试性的特性。
 
在整个过程中，测试员应该注意项目的风险和复杂性是否超过了测试的能力。
 

本文并不是要改变关于需求必须清晰准确的指导方针。本文强调管理风险和关于项目的质量共识之间的关系重要性。