How is Rapid Testing different from normal software testing?

mstiunicon

作者：James Bach 翻译:mstiunicon
快速测试与普通测试的区别
测试实践对于每个行业、每个公司、每个测试人员都是不一样的。但是大多数的测试项目在某些要素上是有共同之处的。让我们把那些有共性的要素称之为“普通测试”吧。在我们的经验中，普通测试包括根据某种规格说明书写一些测试用例。这些测试用例是松散地指导测试人员去测试一个产品的零散的计划或者过程。然后测试人员按照预期的那样在整个产品中执行那些测试用例，重复地，在项目过程中从头到尾地执行。
快速测试与传统测试主要有以下几方面的区别：
1.        首先，不浪费时间。最快速的行动是完全不行动。因此，在快速测试中，我们要消灭掉任何不必要的活动。比较起来，传统测试是比较臃肿的，随之也带来一定的混乱。当然，需要通过一些培训和经验来知道如何来对传统测试“瘦身”。一般地说，流线型的文档（应该是指大量的文档）和虔诚的测试是最容易发生风险的区域。不要因为别人告诉你重复是好的，你就来回的测同一个东西。确保你从每个测试中得到了好的、有价值的信息。要考虑每次测试活动的机会成本
2.        Mission。在快速测试中我们不是以Task为导向（如写测试用例），我们是以Mission为导向的。我们的目标可能是“快点找到重要的问题”。如果是这样，那么写测试用例可能不是最好的方式。另一方面，如果我们的目标是“使FDA听众满意”，那么我们不仅要写测试用例，还要按照指定的规格来写某几种测试用例。理解我们的Mission，然后估算一下我们的形势，并找到我们能朝着实现该目标立即开始执行的最快、最有用的行动。
3.        技巧。做好任何的测试都要求技巧。普通测试不重视测试技巧的重要性，它更多关注测试文档的格式而不是测试的健壮性。快速测试，就像我们描述的，强调测试技巧。它不是像用微波炉炸爆米花那样的机械技术，或者是在DMV（机动车管理部门）填表格。健壮的测试是非常重要的，因此我们练习批判性思维和试验设计技巧。一个测试新手不会在测试中做得很好，除非有一个在测试艺术、技艺上有较高造诣的资深测试人员来监督和指导。我们希望本站点的一些文章能够在这些技巧上帮助你。
4.        风险。普通测试关注功能和结构上的产品覆盖率。换句话说，如果产品能做什么，就测什么。快速测试更关注重要的问题。基于对产品的理解，找出那些我们认为的最可能发生并且发生后影响较大的问题。然后投入我们的主要精力来测试那些问题。快速测试往往意味着尽可能快的揭露最重要的信息。
5.        探索。快速测试也是快速学习，因此我们使用探索性测试。我们避免先写测试用例，除非有明确和强制性的要求。我们更喜欢让上一个测试影响我们的下一个测试。这是一个好事情，因为我们并没有被预先设计好的测试步骤所禁锢，而且让我们发现了更好的测试思想。让测试快速地执行的其它方式，例如很多的测试自动化，总是有着这样的风险――即使运行了大量的非常快速的测试也不能在产品中帮助你找到重要的问题。
6.        启发法。我们必须当心高估所测试的问题，因此我们使用启发法（简单的翻译成：拇指规则）来帮助我们避免思维短路，并且更快地测试。启发法本质上是反应――在某种意义上有偏差地反应――通常是帮助我们在正确地时间测试正确的东西。快速测试收集、记住并且练习使用有帮助的启发法。在普通测试中，启发法也有被使用，但是测试人员往往并不知道自己使用了这个方法，也不能完全地掌控这个方法。
7.        团队合作。快速测试意味着作弊。至少，我们做的事情在以前小学老师的眼中就是作弊：我们尽可能事先弄清楚事情，我们借用其它人的工作，我们使用我们能找到的任何资源和工具。例如，快速测试的一个重要的技术就是成对测试：两个人，一台电脑。这个思想在XP（极限编程）的实践中被证明是有效的，并且在测试工作中也很适用。在普通测试的经验中，测试人员通常安静、独自的工作，而不是像一群迅捷的狼在捕猎bugs。
8.        反省。我们的快速测试人员应该要经常问我们正在做什么和为什么这样做。我们要解析我们自己，并且讨论更好的测试策略和状况。
我正在做一项实验，研究测试在将来成为一个专业的可能性：是否有一个系统化的方式来培训一个有思想、有创造性的人成为一个测试专家？如果有，那么需要多久？是否在一个合理的成本内？对这些问题，我已经有了部分的答案，如果完全回答出这些问题，将可以使测试成为一个有回报的、受尊敬的职业经历。

原文：
How is Rapid Testing different from normal software testing?
Testing practice differs from industry to industry, company to company, and tester to tester. But there are some elements that most test projects have in common. Let's call those common elements "normal testing". In our experience, normal testing involves writing test cases against some kind of specification. These test cases are fragmentary plans or procedures that loosely specify what a tester will do to test the product. The tester is then expected to perform these test cases on the product, repeatedly, throughout the course of the project.
Rapid testing differs from traditional testing in several major ways:
First, Waste No Time. The most rapid action is no action at all. So, in rapid testing we eliminate any activity that isn't necessary. Traditional testing, by comparison, is a bloated mess. It takes some training and experience to know what to eliminate, of course. In general, streamline documentation and devote testing to primarily to risk areas. Don't repeat tests just because someone told you that repetition is good. Make sure that you get good information value from every test. Consider the opportunity cost of each testing activity.
Mission. In Rapid Testing we don't start with a task ("write test cases"), we start with a mission. Our mission may be "find important problems fast". If so, then writing test cases may not be the best approach to the test process. If, on the other hand, our mission is "please the FDA auditors", then we not only will have to write test cases, we'll have to write certain kinds of test cases and present them in a specifically approved format. Proceeding from an understanding of our mission, we take stock of our situation and look for the most efficient and effective actions we can take right now to move towards fulfilling that mission.
Skills. To do any testing well requires skill. Normal testing downplays the importance of skill by focusing on the format of test documentation rather than the robustness of tests. Rapid Testing, as we describe it, highlights skill. It isn't a mechanical technique like making microwave popcorn, or filling out forms at the DMV. Robust tests are very important, so we practice critical thinking and experimental design skills. A novice tester will not do RT very well unless supervised and coached by a senior tester who is trained (or self-trained) in the art. We hope the articles and presentations on this site will help you work on those skills.
Risk. Normal testing is focused on functional and structural product coverage. In other words, if the product can do X, then try X. Rapid Testing focuses on important problems. We gain an understanding of the product we're testing to the point where we can imagine what kinds of problems are more likely to happen and what problems would have more impact if they happened. Then we put most of our effort into testing for those problems. Rapid Testing is concerned with uncovering the most important information as soon as possible.
Heuristics. We must beware of overthinking the testing problem, so we use heuristics (loose translation: rules of thumb) to help us get out of analysis paralysis and test more quickly. Heuristics are essentially reflexes-- biases to respond in a certain way-- that generally help us test the right things at the right time. Rapid Testers collect, memorize and practice using helpful heuristics. In normal testing, heuristics are also used, but testers are often not aware of them and do not fully control them.
Exploration. Rapid Testing is also rapid learning, so we use exploratory testing. We avoid pre-scripting test cases unless there is a clear and compelling need. We prefer to let the next test we do be influenced by the last test we did. This is a good thing, because we're not imprisoned by pre-conceived notions about what we should test, but let ourselves develop better ideas as we go. Other approaches to doing testing quickly, such as extensive test automation, run the risk that you'll end up with a lot of very fast tests that don't help you find the important problems in the product.
Teaming. Rapid Testers cheat. That is, they do things that our former elementary school teachers would consider cheating: we figure things out in advance where possible, we borrow other people's work, we use every resource and tool we can find. For example, one important technique of Rapid Testing is pair testing: two heads, one computer. This idea has proven valuable in the practice of Extreme Programming, and it works for testing just as well. In our experience of normal testing, testers usually work quietly and alone, rather than hunting for bugs like a pack of rapid wolves.
Scrutiny. We Rapid Testers expect to be challenged about what we're doing and why. We practice explaining ourselves and discussing the finer points of test strategy and status.
I am engaged in an ongoing experiment here that may have large implications for the future of testing as a profession: Is there a systematic way to train thoughtful, creative people to be expert testers? If so, how quickly can it be done? And can it be done at a reasonable expense? I have partial answers to these questions, and answering them fully will enable testing to gain the status of a rewarding and respected technical career.

luopapa

好贴,支持+学习ing