光明未来
测试人员点亮道路
这是我们的角色
我们看清事情的面目。
我们通报质量可能性的结果，因为我们批判性的思考软件，
但是
我们让项目负责人做出商业决定
光明未来：
测试拥抱变化和复杂性
真实的世界是混乱和复杂的
变化随时发生
市场决定
合约
需求
规范
设计
文档
产品
系统
我们帮助我们的客户理解变化和复杂性背后的意义
光明未来
调整而不是重复
重复，对于计算机来说，相对容易，但是测试不仅仅是重复。它更是一个开放的探索。
专业的测试因而更关注在思考和调整、价值以及相关的风险上
这种测试是无法脚本化的
专业的测试人员不会问“通过还是失败？”
专业的测试人员会问
这个地方有没有问题？
标准化测试的运动
一个标准对于测试工作的作用是很显著的
前提是你仅仅想发现标准的bug
标准化测试人员的意义
为了扩大测试社区？
为了个别测试人员？
为了已在市场中失败的组织？
还是为了一小群有认证的销售人员
问问你自己
150,000测试人次（至少），每门认证100美元，这 15,000,000美元（至少）的成本去哪了？
谁是ISO29119最激进的拥护者
认证的替代方案
对任何测试任务做好准备
我练习并教授测试
以此我获得成功和失败的经验
我练习批判性思维
以此我避免愚弄自己和他人
我练习系统性思维
以此我学会兼顾全局和细节设计
我练习编码
以此我学会谦卑
我练习描述我的练习
口头的
笔头的（杂志、文章、博客等）
演示的（像现在这样）
我参加到同样工作方式的社区中
认证的替代方案
将思想和知识带入到工作中
我阅读非测试相关的书籍和文章
科学和物理学
数学和统计学
认知心理学和批判性思维
计算机编程和软件设计
食物和烹饪
通用系统
医学
经济学
社会科学
历史
喜剧
我将这些领域原则与测试领域相关联，并描述这些相关性的价值
软件开发
不同于制造业
制造业的目标就是生产出大量的相同部件
重复检查对制造业是有意义的，但是。。。
软件行业，生产出大量同样的拷贝不是个大问题
软件开发
类似于设计
每个新软件产品从某种程度上都是新的，这意味着每次都会有一套新的关系和设计
新的设计不能只是被检查；它们需要被测试
对设计进行测试就如同在罪证化验室中工作
有太多的疑似证据需要测试
有太多的证据相关的工具、过程和来源
工具和过程不是为一个特定调查和目标制定的
工具通常是昂贵的
调查在不确定和苛刻的时间压力下进行
我们的客户（不是我们自己）对可用证据如何处理做出决定
光明未来
测试应关注学习
测试人员在代表我们客户利益的基础上，通过不断学习来维护产品价值
我们所做的不是在确认我们的信念。我们所做的是摧毁不可靠的信念。
测试人员就如同项目团队的感应器
那么我们测试人员是什么？
专业的调查人员
软件测试是对由人、程序以及相关产品和服务组成的系统进行的调查工作。
对于产品应该如何工作，测试人员不必一定要做出结论或推荐。她的任务就是将明确的风险暴露给利益相关者。
什么是测试
优秀的测试工作不仅仅是计算机科学的分支
仅关注程序，遗漏了价值相关的问题以及其他包括人在内的诸多关系
对于我而言，优秀的测试工作就像人类学 – 跨学科的、系统性的、调查性的以及故事性的
光明未来
自动化有很多目的
测试人员的脑力和技能应该围绕探索性的过程上；编程只是一个技能
自动化拓展了我们产生数据，可视化、分析、排序、搜索、观察以及解释数据的能力
自动化不测试；人测试
需求文档不足？
没问题！
如果你抱怨在测试之前缺乏足够的需求文档，那么你就不是真正在做测试；你在做检查
如果你发现需求文档有问题，你的测试已经开始发现有价值的信息
测试工作能够添加很多的信息帮助解决这些问题
光明未来
观察而不是统计
|
不应该考虑 定量标准 数据 Bug数量 完成的测试用例数 通过/失败率 发布测量 每条需求一个测试 数字告诉我们什么 责怪 |
我们应该考虑 定性标准 信息 问题和争议背景 多元覆盖率 “设立是否有问题？” 足够好的质量 风险点 数字遗漏了什么 理解 |
这里目的不在于提供答案，而是给出更好的建议
一条需求不是文档里的一行字或一个段落；那些东西只是表述方式-文字的表示方式-某人有什么和某人想要什么之间是有区别的。用统计需求文档数量的方式统计需求会忽略掉需求背后的一切含义，就如同把三轮车和航天飞机放在一起统计一样。
人们会说有测量总比没有好。那就像说安乐死比没有被枪毙要好。
政治性和感性决策比较强的领域，做一个决策总是基于谁的价值更相关，以及他们的感受如何。测量的目的不在于提供答案，而是提供更好的建议。
我们如何测量
一阶测量
减少琐事，直接观察，减少测量
应习惯于触发控制行为或者提示搜索更多提炼的信息
“发生了什么？我们应该做什么？我们在哪里观察”
Weinberg建议，在软件开发中，我们往往执迷于三阶以及二阶测量，其实一阶测量可能已经满足我们全部的需要-并且无论从各个方面来说都要成本低廉
为什么倾向于一阶测量？
当你在开车时，你大部分精力花在
你的速度、加速度、汽车重量、牵引系数、摩擦力？（三阶）
你的引擎温度、转数以及瞬时油耗？（二阶）
看着窗口以防撞车？
控制测量 vs. 询问测量
一个控制测量是指促成决定的测量方法
任何你用的控制自知系统的测量方法将让系统控制你
一个询问测量是任何帮助你在正确的时间问正确的问题的方法
询问测量有赌博的意思，但是收益会非常低，所以人为操控的可能性几乎没有
测量，从定义上看，是现实的简化版，并且同样的数字能够表示出不同的现实场景。
任何包含人的系统都是自知的。任何你用的控制自知系统的测量方法将让系统控制你。
一个询问测量可能看起来像控制测量。区别就在于你如何用以及如何推断。
观察是在没有定量测量的情况下能够直接做出评估和控制行动的方法。这是一阶方法。要问碰到其他模型怎么办，除了数字类型的，你都可以使用这个方法。应该从你想要解决什么问题或你想要评估什么场景开始问起。与间接观察相比，更应做直接观察。确保你已经考虑了很多可能的解释，然后选择一种控制行为或者搜索以获取更详细的信息。如果你担心观察和评估是主管的（确实），问相关的多个人。
光明未来
通过询问来测量，而不是控制
像通过/失败率以及缺陷发现率这样的度量标准忽略了几乎每个相关因素
需求和bug关联的因素
问题解决的困难程度
产品设计的质量
代码质量
发布时间
谁做出发布决定，为什么
客户采纳的时机
我们用这些虚假的度量标准去评估测试质量？
一行代码代表一个思想。一行代码既能简单到在CPU的寄存器中存放一个值，也能复杂到一个多分支、多条件的判定点。一个开发人员的任务是学习、解决问题，构造和重新构造解决方案。有时这意味着移除代码，而不是添加。评估开发人员做的事情远不止统计有多少行代码这么简单。代码行数的统计是同样愚蠢的测量方法。
什么是探索测试
我接受（也做了一定程度贡献）Kaner的定义，这个定义2007年经过多个会议中的修正。
探索测试是：
一种风格的软件测试方法
强调个体自主权和责任
是针对单个测试人员
为了持续优化他/她工作的价值
通过处理测试设计、测试执行、测试结果说明以及测试相关的学习
作为相互支持的活动
并行的执行
贯穿整个项目
为什么探索？
你不能用一个脚本
调查你已发现的问题
判断脚本是否有问题
避开你已识别出的脚本问题
识别产品中严重的风险
决定组织报告的最佳方式
弄清令人困扰的场景
即使是“脚本”测试人员也一直在探索！
是的，探索测试需要专业技能
探索测试是结构化的
我们已经学习了ET（探索测试）结构，我们已经写下来，我们知道如何教
ET结构有很多来源（非过程化结构，是认知的结构）
测试设计启发
大纲
时间限制
觉察产品风险
具体测试的类型
待测产品的结构
学习产品的过程
开发活动
项目负担的限制和资源
测试人员的技能、才能和兴趣
测试全面的目标
探索测试是可说明的
精简的文档，最小的浪费
详细的过程文档非常昂贵，通常是不需要的。
教程似的文档也通常不需要，但是如果你做了，那么将它和工作文档区分开来。
探索测试是可说明的
基于会议的测试管理
大纲
每个测试会议有一个清晰简明的任务
时间限制
90分钟左右（+/-45）
审核结果
一份会议记录一份测试报告，数据可以被工具扫描、分析和编译。
任务汇报
测试人员和管理者或者测试主管之间的沟通
在实际测试和使用系统过程中，通过摸索不同的测试设计来提炼优秀的测试设计方案。
通过个别监督和简明的测试思路指导测试人员。同时，训练他们能够指导他们自己，能够考虑到可能增加的工作挑战。
探索测试是可管理的
注意检查的角色，尤其是当开发人员编写和维护代码后，需要增加额外的测试组件。
