目录
Testing as Storytelling(测试像讲故事)
Testing as Storytelling(测试像讲故事)
A Short Story Can Be Just as Complete as a Novel短篇小说可以像小说一样完整
Plot Points for a Testing Story绘制测试故事的点
原链接
http://www.satisfice.com/articles/how_much.shtml
翻译内容
Testing as Storytelling(测试像讲故事)
by James Bach
This first appeared on www.StickyMinds.com as a column feature
这篇文章首次作为专栏文章出现在www.StickyMinds.com上
A classic question asked about test strategy is "How much testing is enough?" If you're doing testing strictly from pre-scripted procedures, the answer may seem obvious: You've done enough testing when you've performed all the test procedures. But that answer is not worthy of a thoughtful tester. A thoughtful tester needs a way to answer the question that addresses the mission of testing, not merely its tactics. All the test procedures that currently exist might not be enough to satisfy the mission…or they may be more than needed.
关于测试策略的一个经典问题是“测试多少就足够了？” 如果您正在严格按照预先编写的程序进行测试，答案可能显而易见：当您已经执行了所有测试程序时，您已经完成了足够的测试。 但这个答案不是一个有思想的测试人员的答案。 一个有思想的测试人员需要一种方法来回答解决测试任务的问题，而不仅仅是其策略。 目前存在的所有测试程序可能不足以满足这个任务......或者它们可能超出需要。
Our mission is not to run a certain set of tests. For most of us, our mission is to learn enough important information about the product so that our clients (developers and managers, mainly) can make informed decisions about it.
我们的任务不是运行一系列测试。 对于我们大多数人来说，我们的使命是学习有关产品的足够多的重要信息，以便我们的客户（主要是开发人员和管理人员）能够做出明智的决策。
Testing as Storytelling(测试像讲故事)
When you test, you are doing something much like composing an investigative news story. It's a story about what you know about the product, why you think you know it, and what implications that knowledge has for the project. Everything you do in testing either comprises the story or helps you discover the story. You've done enough testing when you can tell a compelling story about your product that addresses the things that matter to your clients. Since your compelling story amounts to a prediction about how the product will be valued by its users, another way of saying this is that your testing is finished when you believe you can make a test report that will hold true over time—so try to write a classic.
当你进行测试时，你正在做的事情与撰写调查性新闻报道非常类似。 这是一个故事，它是关于您对产品的了解，您认为自己知道它的原因以及知识对项目的影响。 您在测试中所做的一切要么组成了这个故事或帮助您发现这个故事。 当您能够讲述有关您的产品的引人入胜的故事时，您已经做了足够的测试，这个产品解决了对您的客户至关重要的事情。 由于您的引人入胜的故事相当于用户评价产品的一种预测，另一种说法是，当您认为可以制作随时间变化的测试报告时，您的测试就完成了 - 所以尝试写经典的测试报告吧。
For instance, I recently tested the install process of a complex product. My mission was to assess and catalog all the changes that this product made to systems on which it is installed. So my first step was to analyze the install process. Then I diagrammed it, chose test cases corresponding to important parts of that process, and found ways to perform those test cases under controlled and repeatable conditions. I came to a conclusion about this product that flowed logically from the tests, and then I checked the conclusion to be sure that each aspect of it was indeed corroborated and supported by the tests I performed. I needed this to be a good, compelling story, so I tried to anticipate how it could be criticized by “the reader.” Where is my story weak? How might my story turn out to be false? I ran additional tests to rule out other sources of system change. I ran tests multiple times to improve my confidence that the results I was seeing were related to the processes and variables I was controlling, and not coincidental events.
例如，我最近测试了复杂产品的安装过程。我的任务是评估和编目该产品对安装它的系统所做的所有更改。所以我的第一步是分析安装过程。然后我绘制了图表，选择了与该过程的重要部分相对应的测试用例，并找到了在受控和可重复条件下执行这些测试用例的方法。从测试的执行中，我得出了关于这个产品的结论，然后我检查了结论，以确保它的每个方面都得到了我所执行的测试的确认和支持。我需要这个结论是一个好的，令人信服的故事，所以我试着预测它如何被“用户”批评。我的故事的弱点在哪里？我的故事什么情况下会变成假的？我运行了额外的测试来排除系统变化的其他来源。我多次运行测试以提高我的信心，即我看到的结果与我控制的过程和变量有关，而不是巧合事件。
When I exhausted the concerns of my internal critic (and external critics I asked to review my work), I decided it was good enough.
当我对内部批评（以及我要求审查我的工作的外部批评）的担忧感觉“筋疲力尽”时，我觉得它已经足够好了。
A Short Story Can Be Just as Complete as a Novel短篇小说可以像小说一样完整
Testing is potentially an infinite process. If complete testing means you have to run all possible tests, you will never finish. But you can say you're done when you have a testing story with all the major plot points, and you can make the case that additional tests will not significantly change your story. Here's the thing: Although you never know for sure if you have reached that point of diminishing returns, you don't need to know for sure! All that's required, all that anyone can expect of you, is that you have a compelling story for why a thoughtful and responsible tester like you might come to the judgment that you know enough about the product under test. In some situations, that will be months of testing; in other situations, only hours.
测试可能是一个无限的过程。 如果完整测试意味着您必须运行所有可能的测试，那么您永远不会完成。 但是当你有一个包含所有主要情节点的测试故事时，你可以说你已经完成了，你可以证明额外的测试不会显着改变你的故事。 事情就是这样：虽然你永远不知道你是否达到了收益递减的程度，但你无需确切地知道！ 所有人期待的和需要的，就是你有一个令人信服的故事，即一个像你这样有思想和负责任的测试人员，为什么会判断你对被测产品已经有了足够的了解。 在某些情况下，这将是几个月的测试; 在其他情况下，只需要几个小时。
Plot Points for a Testing Story绘制测试故事的点
A complete testing story answers the questions: What was tested (coverage)? In what ways was it tested (techniques)? If problems occurred, how were they detected (evaluation)?
一个完整的测试故事回答了这些问题：测试的内容（覆盖范围）？ 它以何种方式进行测试（技术）？ 如果出现问题，他们是如何被检测到的（评估）？
Whether my test strategy is sturdily scripted, or flowingly exploratory, the plot for my test reports has the same basic structure. It goes like this: Tester meets product. Tester learns product. Product wanders and changes; tester follows it. Tester is worried that product might fail. Tester checks product for possibility of anticipated failures using risk-oriented tests. Tester checks product for unanticipated failures using diversified and coverage-oriented tests. Tester has questions and notices problems and issues. Then, one day, the product settles down, no questions remain, issues are resolved, all known risks have been examined, and all important aspects of the product have been examined. Known problems are either fixed or accepted. Tester has a reasonably clear idea how users will react to the product. Tester lives happily ever after (and so, hopefully, does the product).
无论我的测试策略是固定的脚本，还是流行的探索测试，我的测试报告的图都应该具有相同的基本结构。 它是这样的：测试人员满足产品。 测试人员学习产品。 产品迭代和变化; 测试者跟着它。 测试员担心产品可能会失败。 测试人员使用风险导向测试检查产品是否存在预期故障的可能性。 测试人员使用多样化和面向覆盖的测试来检查产品是否存在意外故障。 测试人员有疑问并注意到问题和要点。 然后，有一天，产品稳定下来，没有问题了，问题得到解决，所有已知风险都已经过检查，产品的所有重要方面都已经过检查。 已知问题被修复了或被接受了。 测试人员对用户如何使用产品有了一个相当清晰的认识。 测试者从此过上幸福的生活（希望产品也是如此）。
Writing a good testing story takes skill and 当心. You'll get it wrong, sometimes. Don't worry too much about being wrong. The main thing is that your story is thoughtful and well researched. Oh, and if you can make it a taut thriller, that won't hurt.
编写一个好的测试故事需要技巧和关怀。 你有时会弄错。 不要过分担心错误。 最重要的是你的故事很全面，研究得很好。 哦，如果你能把它变成一个“紧张的惊悚片”，那就不会受到伤害。