软件测试的两种未来

黑暗未来

像流水线一样测试

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

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

黑暗未来

推进正统教育

Ÿ   所有测试人员必须通过多个容易通过的考试的认证

Ÿ   反正测试不是真正需要专业技能

Ÿ   每个测试产业的从业者使用同样的语言，并且按同样的标准测

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

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

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

黑暗未来

测试和学习无关

Ÿ   测试关注证实、验证和确认

Ÿ   测试人员检查确认规定的测试通过

Ÿ   探索和研究，往好处说是品，往坏处说是危险

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

黑暗未来

测试被简化为无脑的检查

“有脑”意味着“需要人类智慧”

一个“无脑”的活动可以：

被不能思考的机器执行（但是迅速并且精确）；或者被封闭思考的人类来执行（慢并且不可靠）

黑暗未来

测试人员负责制

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

黑暗未来

测试人员负责制

测试人员不能控制日程、预算、产品 、团队、合约等等，但是我们仍然对质量负责。

黑暗未来

测量

Ÿ   我们测量

Ÿ   需求范围，通过统计需求文档数

Ÿ   测试覆盖率，通过统计测试用例数

Ÿ   产品质量，通过统计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。爱因斯坦曾经说过“不是所有有价值的都能被计算，不是所有能计算的都有价值”。我们当然也忽略了他。

糟糕的事情是黑暗未来

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