我称之为快速软件测试。

我们为什么要测试？我们测试以全面了解产品及其周围的风险。我们进行测试以发现威胁产品价值的问题，或者威胁按时，成功完成任何类型的开发工作的问题。我们进行测试以帮助业务，经理和开发人员确定他们所拥有的产品是否是他们想要的产品。

最重要的是，我们测试是因为它是负责任的事情。我们有责任关心我们的团队，组织，客户和社会。发布经过严格测试的软件将违反该义务。

快速软件测试（RST）就是这样。它是一种负责任的软件测试方法，以测试人员和需要测试的人为中心。它是一种方法（在“方法系统”的意义上）包含工具（又名“自动化”），但强调指导和推动过程的熟练技术人员的作用。

这种方法的本质在于它的本体论（我们如何组织和定义各种优先级，想法，活动和其他测试要素），人文主义（我们通过将方法置于每个从业者的控制下来培养责任和应对能力），以及启发式（解决问题的错误方法）。

RST不是一组模板和规则，而是一种心态和技能。这是了解测试的一种方式;这是测试人员知道如何做的一系列事情。

我的意思是迅速

我不是在谈论打字或点击更快。我说的是更好的测试策略。这基本上意味着九件事：

掌控自己的工作。除非您受到对您的工作负责的人的直接监督，否则您不得盲目地遵循任何指示或过程。这意味着您使用的任何实践，无论您如何与项目中的其他流程协调，请自行决定。不要将测试基于您不理解的测试用例。如果您不了解某些事情，请在研究之前研究它，停止这样做，或者建议您的客户盲目地工作。
停止做有帮助的事情。很难说哪些活动真的是浪费时间而哪些不是浪费时间，但这是一条黄金法则：如果你认为自己在做一些浪费时间的事情，就不要再做了。
拥抱探索和实验。快速做好测试的一部分是快速了解产品，这不仅仅需要阅读规范或重新利用旧的测试用例。您必须潜入并与产品互动。这有助于您更快地建立它的心理模型。
专注于产品风险。一种尺寸的测试并不适合所有人。在需要的地方进行更深入的测试，并在潜在的产品风险较低时进行浅层测试或根本不进行测试。
使用轻量级，灵活的启发式方法来指导您的工作。 RST方法包括许多旨在帮助构建您的工作的启发式模型。这些模型简洁明了，可用于支持从自发和非正式测试到审议和正式测试的任何级别的测试。它们始终在您的控制之下。
使用解决问题的最简洁的文档形式。文档可能会对任何项目造成巨大拖累。它很难创建并且难以维护。要么避免它，要么使用最轻的形式的文档来传达需要它的特定人员所需要的东西。
使用工具加速工作。测试人员不一定需要编写代码，但他们确实需要强大的工具。无论您是自己创建工具还是寻求其他人的帮助，您都可以将工具（包括自动检查）应用于测试过程的所有方面
解释你的测试及其价值。当您能够以注重价值的方式清晰快速地解释测试的重要性时，您的客户和团队成员将会感觉到您的时间得到充分利用，因此足够快。
提高您的技能，以便您可以完成上述所有工作。我们不提供可以吞咽的药丸，让您可以做这些事情。但我们确实向您展示了如何发展您的技能，以及如何发展它们。通过培养判断力和对不同技术，工具和流程的广泛了解，您可以选择一种快速的测试方法来满足所有业务需求。

想了解详情？

以下是RST的许多元素的路线图：

可以在此处找到一些表达RST的参考文档。

RST的基础是什么？

RST受到Gerald M. Weinberg，Cem Kaner和Billy Vaughan Koen，以及社会学家Harry Collins，家庭治疗师Virginia Satir以及诺贝尔奖获得者Herbert Simon，Richard Feynman，工作和科学方法的强烈影响。和Daniel Kahneman。如果您钦佩他们的工作，您会发现很多因我们提供的方法和课堂体验而产生共鸣。

RST还基于Cem Kaner，James Bach和Bret Pettichord的“软件测试经验教训：上下文驱动的方法”并与之相关。以及我的书“海盗 - 学者的秘密”中描述的自我教育和独立思考的生活方式。

以下是RST的具体前提，由我和Michael Bolton撰写。方法论中的所有内容都以某种方式来自这个基础。这些前提来自我几十年的经验，研究和讨论。

软件项目和产品是人与人之间的关系，人是情感和理性思想的生物。是的，还有技术，物理和逻辑元素，这些元素非常重要。但软件开发主要受人类方面的影响：政治，情感，心理，感知和认知。项目经理可以声明任何给定的技术问题对于企业来说根本不是问题。用户可能需要他们永远不会使用的功能。你的神奇工作可能会被拒绝，因为程序员不喜欢你。新手用户的足够快的性能对于有经验的用户来说可能是不可接受的。对于重要的人来说，质量始终是有价值的。产品质量是产品与人之间的关系，绝不是可以与人类环境隔离的属性。
每个项目都在不确定和时间压力的条件下进行。某些程度的混乱，复杂性，波动性和紧迫性困扰着每个项目。混乱可能是瘫痪，复杂性压倒性，波动性令人震惊，紧迫性迫在眉睫。原因很简单：新颖，雄心和经济。每个软件项目都试图生成新的东西，以解决问题。软件开发人员渴望解决这些问题。与此同时，他们经常尝试做的事情远远超过他们所拥有的资源。这不是人类的任何道德错误。相反，它是演化理论所谓的“红皇后”效应的结果：你必须尽可能快地跑到同一个地方。如果您的组织没有承担风险，您的竞争对手将 - 并最终您将为他们工作，或根本不工作。
尽管我们有最好的希望和意图，但某种程度的缺乏经验，粗心大意和无能是正常的。这个前提很容易验证。首先要诚实地看待自己。您是否拥有在不熟悉的领域或不熟悉的产品中工作所需的所有知识和经验？你有没有犯过你没有抓到的拼写错误？您仔细阅读了哪些测试教科书？你有多少学术论文？您是否熟悉集合论，图论和组合学？你是否精通至少一种编程语言？您现在可以坐下来使用de Bruijn序列来优化您的测试数据吗？你知道什么时候避免使用它吗？您是否完全熟悉所测试产品中使用的所有技术？可能不 - 而且没关系。创新的软件开发工作的本质是扩展即使是最有能力的人的极限。其他方法似乎假设每个人都能够并且将会在正确的时间做正确的事情。我们发现这令人难以置信。任何忽视人类易犯错误的方法都是幻想。通过说人类的错误是正常的，我们不是试图为它辩护或为它道歉，但我们指出，我们必须期望在我们自己和其他人中遇到它，以富有同情心的方式处理它，并充分利用它我们学习手艺和建立技能的机会。
测试是一项活动;它是性能，而不是工件。大多数测试人员会随便说他们“编写测试”或者他们“创建测试用例。”这很好，就目前而言。这意味着他们构思了想法，数据，程序，以及可能使某项任务或其他任务自动化的程序;他们可能已经用书面或程序代码表达了这些想法。当任何这些事物与它们所代表的想法混淆时，以及当表示与实际测试产品混淆时，就会出现问题。这是一种称为物化的谬误，即将抽象视为事物的错误。在某个测试人员使用该产品之前，观察并解释这些观察结果，没有进行任何测试。即使您编写了一个完全自动的检查流程，该流程的结果也必须由负责人审核和解释。
测试的目的是发现产品的状态及其价值的任何威胁，以便我们的客户能够做出明智的决策。当人们使用“测试”这个词时，会有其他目的。对于某些人来说，测试可能是检查基本功能似乎有效的一种仪式。这不是我们的观点。我们正在寻找重要的问题。我们寻求对产品的全面了解。我们这样做是为了满足客户的需求，无论他们是谁。为客户服务所需的测试水平会有所不同。在某些情况下，测试将更加正式和简单，在其他情况下，非正式和精细。在所有情况下，测试人员都必须向那些必须对其做出决策的人提供有关产品的重要信息。测试人员照亮了路。
我们承诺进行可信的，具有成本效益的测试，并且我们将告知客户任何威胁该承诺的事情。 Rapid Testing寻求完全满足测试任务的最快，最便宜的测试。当10美元的测试能够完成这项工作时，我们不应该建议进行百万美元的测试。我们测试得还不够;鉴于项目的局限性，我们必须进行良好的测试。此外，当我们受到一些可能妨碍我们做好工作的约束时，测试人员必须与客户合作解决这些问题。无论我们做什么，我们都必须准备好证明和解释它。
我们不会故意或疏忽地误导我们的客户和同事。这种道德前提推动了快速软件测试的许多结构。测试人员经常成为客户善意但无理或无知的要求的目标。我们可能会被要求压制坏消息，创建我们无意使用的测试文档，或者生成无效指标来衡量进度。我们必须礼貌而坚决地抵制这些要求，除非我们认为它们符合我们客户的更好利益。至少我们必须告知客户任何阻碍我们测试的任务或工作模式的影响，或者造成测试的错误印象。
尽管测试人员无法控制产品的质量，但他们对工作质量负责。测试需要许多互锁技能。测试是一项工程活动，需要大量的设计工作来构思和执行。像许多其他高度认知的工作一样，例如调查报告，驾驶飞机或编程，对于没有实际工作的人来说很难有效地监督它。因此，测试人员不得放弃对自己工作的责任。出于同样的原因，我们不能对产品本身的质量承担责任，因为它不在我们的控制范围内。只有程序员和他们的管理层才能控制。有时测试称为“质量保证”。如果是这样，请将其视为质量协助，而非质量保证。

RST的演变

快速软件测试的起源是我在Apple Computer和Borland International运行测试团队的经历，可以追溯到1987年。我一直在寻找测试的本质，而不是在当时的任何标准或书籍中找到它。然后我收到了Ed Yourdon，Tom DeMarco，Tim Lister和Jerry Weinberg的重要线索。他们促使我考虑一般系统思考。他们开始思考心理学在工程学中的关键作用。然后在90年代中期，在旧金山举行的测试会议上进行的通宵谈话中，Cem Kaner敦促我探索认知心理学和认识论。这些领域提供了我新兴方法的组织框架。

我曾经给出的关于测试方法的第一次谈话叫做动态软件质量保证。我是在1990年为Apple大学做过的。我希望我还有那个录像带。这是我最后一次没有留胡子的视频。我在谈论启发式和系统思考，但我认为我不知道这些话。

我在1993年举行的第一次重要的会议讨论叫做“持久性特别测试”。我在谈论探索性测试的非凡价值，尽管我不会在今年晚些时候开始使用该术语。

我的测试方法的第一个公开版本体现在1995年的一个名为市场驱动的软件测试的类中。然后我创建了一个基于风险的测试课程，以及业界第一个探索性测试课程。 2001年，我将这些课程结合起来，开始将该方法正式化，将课程重命名为Rapid Software Testing。

2004年，Michael Bolton将他作为开发人员，测试人员，文档管理员和项目经理的经验带到课堂上，添加了新的练习，谜题和主题。 Michael在商业和金融服务软件方面的工作增加并影响了关于形式和文档角色的想法，并于2006年成为该课程和方法的共同作者。多年来，他帮助改进了RST，提高了词汇量，并在检查 - 原则上可以由机械完成的测试的一部分 - 和测试之间引入了至关重要的区别 - 这需要测试人员的明确和隐性知识。

Paul Holland（来自嵌入式系统和电信），Huib Schoots（金融服务）和Griffin Jones（医疗设备和其他监管领域）各自将他们的想法，经验和教学方式融入其中。我们的每位教师都受益于其他人的工作，每个人都教授自己的个人RST变体。

RST历来专注于测试和测试人员。但是我们最近重新调整了一点，因为许多进行测试的人要么没有被称为测试人员，要么除了测试之外还做其他事情。如今，我们的客户需要了解RST如何与Agile和DevOps集成。

这是我们的敏捷快速测试网格，它可以帮助我们解释：

方法与什么兼容

RST是一种上下文驱动的方法。这意味着我们的课程不是专门针对敏捷，DevOps，精益，瀑布或受监管环境中的测试;它也不包含您可能用于模拟用户或支持任何其他测试方面的任何特定测试工具。但是，我们通过让您控制流程来帮助您将这些内容应用于测试，以便您解决实际存在于您的上下文中的问题。

关键问题是责任。作为测试人员，责任意味着做出独立的专业判断，以应用实践和工具来发现您特定项目的每个重要问题。责任意味着在项目和产品风险需要时进行深度测试。负责任地应用诸如“单元测试”或“行为驱动的开发”之类的实践意味着在适合您的环境时选择它，而不是因为您听说Facebook和Google这样做，或者因为您被命令这样做。负责任地使用自动化包括在更有效，更高效或解决自动化忽略的问题时考虑自动化之外的方法。责任意味着当你说“可能什么都不会出错”时，你不仅仅是在猜测。

RST不告诉你该怎么做。相反，它是一个负责任和有文化地考虑做什么的框架。 RST的教师具有广泛的环境经验，可以帮助您定制材料以满足您的需求。因此，我们有很多关于如何将自动化应用于测试，或如何在文档密集型项目中进行良好测试的想法。

有一点特别是RST方法与以下方面不兼容：假测试。是的，有些组织有目的地最大限度地利用文书工作，并鼓励他们知道很少发现错误的浅层测试脚本。 “工厂式”测试通常相当于假测试，因为它看起来很合理，尽管未达到其明显的目的。一些公司 - 大型测试外包公司因此而闻名 - 甚至这是一种商业模式，可以最大化计费时间。这些公司不希望更有效地进行测试，因为这会减少他们的计费时间。他们希望对那些不了解深度测试的人看起来很有成效。如果您为这样的公司工作，如果您参加RST课程，您的老板会非常恼火。它会让你提出不舒服的问题。

以下是有关RST如何与其他一些流行的测试方法进行比较的其他详细信息。

原文:https://www.satisfice.com/rapid-testing-methodology

讨论: 知识星球【数字化和智能转型】