2012年2月，詹姆斯·巴赫和我一起一对一的、面对面的做了一个星期的工作——这期间很少有事情发生。我们在一起做许多事情，但是最重要的结果是一个语句的前提是基于快速软件测试——我们的类和方法的。考虑到像我一样的Twitter的大小的注意力，我会把前提在接下来的几天。我会在未来几天把前提发布出来。这里是序言和第一点：
这些都是快速软件测试方法的前提。一切方法都是在此基础上以某种方式派生出来的。这些前提来自于我们的经验，研究和一段超过几十年的讨论。他们一直受到影响的两个重要的思想家： Cem Kaner 和 Jerry Weinberg，两人都担任过程序员，项目管理者，社会科学家，作家，教师，当然，也担任过测试人员。 （我们并不认为Cem或Jerry会总是同意James或我，或相互同意。有时他们会不同意。这里我们并不需要他们的认可，恰恰相反我们感谢他们的积极的影响我们的思想和我们的工作，我们敦促思维测试人员到处研究这两个人的著作和想法。）
1、软件项目和产品是那些既有情感又有理性思维的人们之间的关系。是的，有技术，物理和逻辑元素，这些元素是非常重大的。但是软件开发主要是由人的方面主导的：政治、情感、心理学、看法和认知。对于所有业务，项目经理可能宣布任何给定的技术问题并不是一个问题。用户可能提出他们那些他们永远不会使用的特性需求。你的难以置信的工作可能会被拒绝，因为程序员不喜欢你。对于有经验的用户来说可能不能接受一个新手用户有足够快的反应。质量总是对于那些关心的人来说是有价值。产品质量是一个产品和人之间的关系，从来没有一个属性可以从人类的环境中分离出去。
2、每个项目发生在不确定性和时间上的压力的情况下。某种程度的混乱、复杂性、波动性和紧迫性困扰着每个项目。混乱可能是严重的，势不可挡的复杂性，令人震惊的波动和绝望的紧迫性。这里有一些简单的原因：新颖性、野心和经济。每个软件项目都是为了解决一个问题而试图生产出新的东西。软件开发人员都急于解决这些问题。与此同时，他们经常尝试用已有资源做一大堆超过他们本可以轻松处理的事情。这不是任何一种的人类道德过错。相反，它是进化理论里所谓的“红皇后”效应的一个后果（名字来自于透过镜子看）：你必须跑的足够快，你可以仅仅停留在同一个地方。如果你的团队不管理风险，你的竞争对手会——最终你将会为他们工作，或者根本不工作。
3、尽管我们最好的希望和意图在某种程度的缺乏经验，粗心大意和能力不足，但这也是正常的。这个前提是容易验证的。首先是正视自己。在一个陌生的领域工作，或做一个不熟悉的产品时，你有你需要的所有知识和经验吗？你是否曾经犯过一个拼写错误但你没发现？哪本测试教科书你曾经仔细阅读过？有多少学术论文你仔细研究过？你了解集合论、图论、组合数学的最新情况吗？你能讲一口流利的至少一个编程语言吗？你能现在坐下来并使用de Bruijn序列来优化您的测试数据吗？你会知道什么时候应该避免使用它吗？你在进行产品测试时，你完全熟悉用于测试的所有技术吗？大概不会，没关系。它的本质是创新的软件开发工作，延伸工作极限，即使是最能干的人。其他的测试和开发方法似乎假定每个人都能够并且将会在正确的时间做正确的事。我们发现这是令人难以置信的。任何忽略了人的易错性的方法都是一种幻想。说人类易犯错是正常的，我们并不打算为它辩护或表示歉意，但我们指出，我们一定会遇到对自己和对他人的同情地处理这个问题的人，并充分利用我们的机会学习我们的工艺，并建立自己的技能。
……………………
查看全文请点击下载：http://www.51testing.com/html/11/n-832511.html
6、我们承诺执行可靠的，具有成本效益的测试，我们会及时通知我们的客户任何威胁到这一承诺的情况。快速软件测试寻找最快、最便宜的测试，完全满足测试的任务。当十美元的测试能够完成这项工作时，我们不应该建议花费百万美元来做测试。我们要做好测试这是不够的，我们测试；我们必须在给定项目的限制因素内将测试做好。此外，当我们在限制条件下时，这些约束可能阻止我们做好工作，测试人员必须与客户合作解决这些问题。无论我们做什么，我们必须做好准备去证明和解释它。
7、我们不会故意或过失误导我们的客户和同事。这种伦理的前提下驱动了很多的快速软件测试的架构。测试人员经常碰到他们的客户要求的善意的但不合理的或无知目标。我们可能会被要求隐瞒坏消息，来创建测试文档，我们不打算使用，或者产生无效的指标来衡量进展。我们必须礼貌而坚决地抵制这样的请求，除非根据我们的判断，他们为我们的客户提供更好的利益。至少我们必须通知我们的客户任何任务或工作方式阻止我们测试的影响，或创建一个虚假印象的测试。
8、测试人员承担在他们工作中对质量的责任，尽管他们不能控制产品的质量。测试需要很多环环相扣的技能。测试是一个工程活动，需要相当大的设计构思和执行工作。像许多其他高认知的工作，比如调查性报道，驾驶飞机或编程，很难有人没有实际做过这份工作却能有效地监督管理。因此，测试人员必须不能推卸对自己工作的质量的责任。出于同样的原因，我们不能对产品本身的质量承担责任，因为它不是在我们的控制范围内。只有程序员和他们的项目经理控制管理他们。有时测试被称为“QA”。如果是这样，我们选择把它看作质量援助（Cem Kaner的想法）或质量意识，而不是质量保证。
查看全文请点击下载：http://www.51testing.com/html/11/n-832511.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
