在黑暗未来，测试人员的角色-请原谅我，质量保障分析师-就是为了阻止变更。我们原本相信对产品和项目足够了解，但是变更使得这件事可能不再有效，于是变更引入了风险。所以即使客户需求、市场条件、日程、预算、产品范围、团队以及项目以外的任何事情可能发生了变化，我们仍然坚持原有的过程，坚决按计划行事。即使我们在研发产品的过程中不断学到一些新的东西，也不要影响计划；我们应该在事先了解那些事情。我们的责任不仅仅是告知，我们还必须死板的执行。

         在黑暗未来，ISO标准29119会告诉我们需要测试什么以及如何测试。“无论你做的是哪种类型的测试，它都会影响你。”即使起草标准的人不知道你的业务也没关系嘛；因为他们是“专家”，他们知道什么方式是好的方式，比你更知道。“标准使用了四层过程模型，开始有两个层覆盖测试策略和测试战略。下一层转向项目管理，最后一层为所有测试级别定义了基础测试过程，比如单元测试，系统测试，验收测试，以及测试类型（例如性能和可用性测试）。第2和3部分，与过程和文档相关，特别与测试过程潜在的所有输出紧密关联，相当于文档部分定义的文档。同时建议使用‘新工作项目’，这个将在测试过程改进中看到第五部分内容-假设一个测试产业每隔数十年没有出现其他新的测试改进模型。”是不是听起来很不错？他们不仅仅告诉你如何去做，还包括如何改进-而不顾广为人知的警告，“可能最大的抱怨来源于IT标准不能满足实际从业者的需求-我们中的很多人都会遇到这种‘空文’”。也不要担心标准难以管理，当前标准的第2部分草稿，就是在编写的这部分，“仅”100页。

         注意和标准相关的还有标准的术语表。术语表用英语。将它翻译成其他语言会增加复杂度和模糊性。让我们所有人仅仅用英语测试吧。如果其他文化不喜欢。。。好吧，有点困难。反正也没多少从他们那需要学习的东西。

         在黑暗未来，评估测试人员的能力是基于记忆权威知识体系中测试术语的能力。上下文环境和理解说明在黑暗未来没有容身之处。考试总是需要的，这样便于考认证，所以有多个认证的选择也是必须的。如果担心这种方法不足以评估技能，不用担心：测试反正不是一个特别需要经验的行业。一些测试人员能够编写代码让工作自动化，这个是一个好主意，因为无论从什么角度看测试总是一个枯燥、重复以及单调的任务。

    我们不希望测试人员和开发人员（即程序员-程序员仅仅指黑暗未来里的开发人员）亲近。测试人员会意志薄弱以至于受到程序员负面的影响，所以这种亲近会危害测试人员的目标。测试人员可能会被诱导不要报bug。

    重复在黑暗未来中是非常重要的。我们想要一遍又一遍的跑同样的测试，没有变化，因为变化可能导致不可预测性。发现和研究bug会让我们脱离原定计划。

         在黑暗未来，测试是持续不断的例行任务，机械化的活动，即使它们是由人完成的。它和学习无关，和确认我们已知的事情有关，回答我们知道答案的问题，重复一遍又一遍同样的无脑测试。在黑暗未来，没有探索、研究或发现、学习的地方，也就是没有技能、创造性和想象力生长的舞台。也没有询问客户如何评估我们产品的空间。我们只是做我们被告知的，我们不学习任何东西。

         在黑暗未来，测试人员是质量的看门人。我们决定何时开始测试，仅仅当产品和相关文档按严格标准提供时，以及当我们收到完整的、无歧义的、最新的需求文档时，我们开始测试。我们决定产品质量是否达到发布的要求。管理者必须得到我们的签名和我们的允许，才能发布一个合格的产品。我们能够中止发布，如果我们认为产品不够好。当然我们自己不需要遵守这些标准，那不是我们的工作。在黑暗未来，我们的角色是告诉其他人他们什么做错了以及如何改正。在黑暗未来，测试人员是真正的项目管理者。

         需求文档、生产率、复杂度、测试覆盖率、产品质量以及测试人员价值与我们看到的成百上千的因素有关。然而大部分因素并不能明确的量化，过分简化的统计只能是误入歧途。在黑暗未来，我们解决问题的办法是忽略他们。

         一个bug并不是这个世界上的普通的一件事情。一个bug是结构化、充分思考的精神产物。它是特定人和特定产品之间的关系，比如其他的人可能不会把它视之为bug。甚至当两个或更多人认为部分行为似乎一个bug时。他们也可能不同意这是个明显的bug。尽管如此，在黑暗未来，我们会统计它们。越多的bug意味着越高的质量；越少的bug意味着越低的质量。这对测试人员同样适用。我们会忽略所有测试人员带给项目的其他活动和维度的价值，通过统计他们bug报告的数量来测量他们的工作效率。

         在黑暗未来，我们不会做定性的测量、做第一手的观察、看测试人员和开发人员的交流，或者和实际用户进行沟通。我们不相信故事，只相信统计。然而我们不会担心测量方法中的合理性或其他可能的问题。我们只是简单的使用方法，比如应该对每个需求文档有一个可追溯的测试用例。不，等等！应该是两个！一个正向测试用例和一个负向测试用例。

         Cem Kaner说过一个测试用例是我们想要问这个产品的一个问题。James Bach也多次说过，一个测试用例是一个问题的容器。在黑暗未来，我们评估工作质量，是坐在办公室里，统计每天早上进进出出的公文数量。我们不去考虑看一下其中的内容。如果公文的数量越多，那就显而易见的表示公司的工作效率在提升。

         我们忽略简单统计背后隐藏的问题，回避Cem Kaner和Pat Bond所著的Software Engineering Metrics:What Do They Measure and How Do We Know?(http://www.kaner.com/pdfs/metrics2004.pdf); Darrell Huff 经典的How To Lie With Statistics; Gerald M. Weinberg所著的Quality Software Management, Vol. 2: First Order Metrics ; 尤其是Robert D. Austin所著的Measuring and Managing Performance in Organizations。爱因斯坦曾经说过“不是所有有价值的都能被计算，不是所有能计算的都有价值”。我们当然也忽略了他。

         在黑暗未来，在项目管理比较便于测试人员操作时，他们会在幕后驱动整个项目。即使测试人员明显没有什么权力，他们仍然对所有质量过失负责。因为他们是代码最后的经手人，于是看上去任何没有被检测到的问题都是他们的过失。测试人员必须签署文档来决定产品是否可以发布，即使产品的发布是一个商业层面的决定，而不是技术层面的。

         在黑暗未来，所有产品的失败被视为测试失败。没有人承认问题是整个研发团队的问题。阅读每天的报纸，你会发现一个又一个问题被贴上了糟糕测试的标签。不是糟糕的编程，不是糟糕的项目管理，不是糟糕的产品理念，不是糟糕的产品需求。一个通行的观点就是，产品问题就是测试问题，不多，不少；在这个观点下，如果软件研发是一场球赛，比赛输掉的所有责任都在守门员。