颠覆完美软件：软件测试必须知道的几件事（读书笔记5）

9、一种改善软件测试沟通问题的模型（第十一、十二、13和14章）

　　本部分经过介绍萨提亚交互模型：摄取-->肯定含义-->肯定重要性-->作出反应，来应对软件测试和项目推动过程当中的相关问题。

　　一、萨提亚模型

　　　　萨提亚模型将任何沟经过程都分解成四个阶段：摄取、肯定含义、肯定重要性和作出反应。

　　　　摄取（Intake）：一我的从外部世界取得信息，摄取不是简单的输入，还包括信息的选择过程。

　　　　肯定含义（Meaning）：某人会对感官摄取的内容进行考虑并给它一个含义。

　　　　肯定重要性（Significance）：肯定信息的重要性，可让某些摄取及其含义得到优先权。

　　　　作出反应（Response）：一我的会构想出准备采起的行动。

　　二、信息摄取

　　　　摄取是一个主动的过程。要尽量地了解那些限制摄取的因素、信息的来源，以及数据如何得到了带有误差的含义。被动地等待别人给你的数据，也许不会让你成为受害者，但至少能够潜在控制你会获得哪些数据。

　　　　2.1 人们听取的信息是有选择性的

　　　　经理们尤为选择性听取有关发布和交付日期。若是测试人员说，根据目前发现和修复缺陷的速率，几乎不可能在9月1日以前交付。经理可能会听成，9月1日前交付。为了不这类问题，有两种方式：1.只采用书面形式给出和接受某个日期；2.不要给出或接受“点日期”，要这么说，估计会在8月1日到8月21日发布某个版本。

　　　　2.2 数据来源会影响到摄取

　　　　若是有些人不肯意接受你的测试报告，而愿意接受其余人递交的报告。你能够从本身找找缘由：1.本身之前是否是作过什么让你们认为我不是一个可靠的信息来源的事。2.我应该作些什么来提升他们对我做为信息来源的信任。

　　　　2.3 提供信息的时机也会致使差别

　　　　别人将注意力转向其它地方的时候会遗漏某些信息。若是没有获得别人的注意，就没有什么必要提供信息，由于对方不太可能接受这些信息。

　　　　2.4 人们会出现信息过载

　　　　人们受到过多信息，会中止或者在必定程度上减小摄取信息。好比缺陷数目太多，就是信息过载，这时候不知道应该先处理哪个缺陷。

　　　　好的方法是，将缺陷按照重要性进行分类。将缺陷报告类别分为4个级别：0级、1级、2级和3级。

　　　　0级：阻碍其余测试，未能在1分钟内进行分类。

　　　　1级：该问题没有解决，产品不能交付。

　　　　2级：该问题没有解决，产品的价值会显著下降。

　　　　3级：产品交付时有大量相似问题，该缺陷才是重要的。

　　　　2.5 减小测试的数量能够传递更多信息

　　　　经过回答“哪些测试会对未来的测试和开发产生最大的影响”这个问题能够缩减可能的测试集合，进而经过不多的测试数量，就能够传递很重要的信息。

　　　　2.6 寻找测试以外的信息摄取

　　　　测试以外，是否是有其余缘由也会致使问题，好比静电、震动、雷达等。一台测试机器没有按预期方式工做，多是别人使用后更改其状态。

　　　　2.7 不要混淆理解和摄取

　　　　当人们根据随机的一点数据，猜想这些数据的含义时，就会很是迅速地从摄取阶段移动到肯定含义的阶段。

　　　　2.8 使用数据质疑来过滤理解

　　　　当某人在你须要数据的时候向你提供对测试的理解，可使用数据质疑的方法：“你看到或听到（或者闻到、尝到、感受到）让你产生这样的理解？”，一般须要重复数据质疑，直到获得你所指望的不带含义的数据。

　　　　2.9 相关常识

　　　　1.你须要对接受的信息进行选择，不要来了什么信息就去接受。

　　　　2.测试工做中获得的信息中有99%是没有用的，你要有一双慧眼，从大量数据中捕获有用的信息。

　　　　3.不要混淆摄取和含义：

　　　　　　在肯定数据以前，数据时没有意义的；对相同的数据，不一样的人会给出不一样的含义。

　　　　　　先收集数据，而后坐下来考虑这些数据可能具备的至少三种含义。

　　　　4.不要禁止测试人员在某些地方寻找缺陷，应扩展测试人员的思惟。

　　　　5.要为测试人员提供充足的设备和工具。

　　　　6.有些昂贵的测试工具自己设计有问题、而且不可靠，那就大胆的抛弃它。

　　三、肯定含义

　　　　数据自己是没有意义的，须要由接收的人给它加上含义，而不一样的人会给出不一样的含义。因此对一样的数据最好给他多种可能的解释。若是对测试结果不能想出至少三种可能的解释，就说明思考得还不够。

　　　　3.1 对缺陷要思考多种含义

　　　　对缺陷进行解释以肯定含义须要勤奋和开放的态度。同时对缺陷而想到的含义应该越多越好。

　　　　3.2 解释含义以前应弄清楚指望的是什么

　　　　若是不清楚一个程序被指望作什么，就永远不能肯定地说它是错误的。在你给测试报告赋予含义以前，先要弄清楚你指望的是什么。

　　　　3.3 不知道指望时的作法

　　　　若是在解释测试结果时不清楚产品被指望要作什么，能够提出下列问题。

　　　　1.它是否完成了重要的人但愿它完成的工做？

　　　　2.它是否没有作重要的人不但愿它作的事？

　　　　3.这些测试结果告诉我哪些与这个两个问题有有关的状况？

　　　　3.4 使用已经得到的信息

　　　　肯定测试报告的含义时须要考虑测试报告中未包含的信息。可是在盲目地要求更多的信息前，应该从已经得到信息入手。要充分地利用已经得到的信息。

　　　　3.5 使用间接信息

　　　　间接信息包括：每一个测试运行的日期和时间，报告提交的日期和时间，测试是谁运行的，每份报告是谁提交的，测试的软件及其版本的明确标识，使用的操做系统、浏览器、计算机、配置，测试工具和原始开发语言，对较早缺陷报告的引用，及各类形式的补充说明。

　　　　只有利用这些彷佛是附属品的数据才有可能理解不少最困难的缺陷。

　　　　3.6 使用未得到的信息

　　　　根据缺失的信息推断含义。

　　　　3.7 一样的话可能具备不一样的含义

　　　　3.8 “相同”可能并不同

　　　　表面相同，但实际来自于不一样来源的事物进行理解时要保持怀疑的态度。

　　　　3.9 某些时候不精确会更好

　　　　在试图对含义进行沟通时，有时候使用模糊的语言更有效。

　　　　3.10 相关常识

　　　　1.根据“三法则”，在采起行动以前至少考虑三种可能的含义。

　　　　2.在测试以前，要记录好对测试结果的预期。

　　　　3.不要彻底靠本身肯定含义，要让整个团队都参与进来，从而下降忽略某个重要结论的可能性。由于不一样思惟会肯定不一样的含义。

　　　　4.肯定数据含义时使用“三法则”是不够的。对不一样的人而言，一样的含义可能具备彻底不一样的重要性。不一样的思惟会肯定不一样的重要性。　　　

　　四、肯定重要性

　　　　重要性是由负责决定要如何对缺陷进行处理的人赋予该缺陷的价值。每一个人由于思惟的不一样，所肯定的重要性都是不同的。若是咱们注意情绪，认真听取，先解决重要的事情再解决不重要的事，就能够对得到的数据作出最好的处理。　

　　　　4.1 不一样人会给一样的信息赋予不一样的重要性

　　　　做为项目经理，工做就是将全部见解放在一块儿进行权衡，并得出这个缺陷对于整个项目的重要性。--前提条件是它确实是一个缺陷。

　　　　4.2 公共的重要性也许和我的的不同

　　　　若是每一个人都是合乎逻辑的、公正的、开放的，对重要性的评估就会很简单。可是，可能每一个人对缺陷问题作出重要性的回答时都参杂了我的打算在其中。若是项目经理想对重要性作出明智的估算，就要想办法消除全部这些我的打算，包括项目经理本身在内。

　　　　4.3 重要性依赖于上下文环境

　　　　重要性不只取决于单个缺陷和单我的的一项性质，还依赖于上下文环境。

　　　　1.某段代码，第一次出现缺陷和屡次出现缺陷，评定第n次缺陷的重要性是不一样的

　　　　　　某段代码，第n次出现问题，可能意味着之后还会发现更多的错误。这就是记录全部缺陷的缘由。

　　　　2.对某个用户可能碰到的程序缺陷的可能性进行猜想

　　　　　　一百亿用户中只有一个用户可能遇到这种缺陷，重要性如何呢？

　　　　4.4 不能老是根据金钱来肯定重要性

　　　　好比说人的生命。

　　　　4.5 不要采用过细的尺度

　　　　由于全部对重要性的度量都是主观的，不要愚蠢地让本身相信重要性是客观的。

　　　　将评定重要性的类别数量变为4个，该评定类别可让测试人员从测试角度肯定重要性。

　　　　0级：该问题阻碍了其余测试。

　　　　1级：若是该问题不解决，咱们的产品就没法使用。

　　　　2级：若是该问题不解决，咱们产品的价值就会显著下降。

　　　　3级：只有在产品交付时还存在大量相似问题时，该问题才是重要的。

　　　　4.6 首先解决重要问题

　　　　对已发现的故障，应先解决重要性高的故障。而经过对测试的重要性进行估计，首先执行那些重要的测试。

　　　　4.7相关常识

　　　　1.混淆重要性和修改的难度。

　　　　　　好比，系统崩溃的问题多是不重要，而某个拼写错误确实是灾难性的。

　　　　2.认为有“理性的”或者客观的方法来评估重要性：

　　　　　　也许可使用数字和算法来为评估重要性提供帮助，可是最终的评估步骤老是要度量人对那些数字的情绪反应。

　　　　3.得到新信息后也要从新评估重要性。

　　　　　　重要性是整个系统的一种性质，包括用于构建该系统的系统或过程。常常回顾对重要性作出的评估，并作好改变它的准备。

　　　　4.不要让废话影响到对重要性的评估：有意或无心使用，某些会掩盖有意的信息的词。

　　　　　　好比，某人说“反应应该会很是快”的时候，究竟是什么意思呢？“应该”，“很是”和“快”给表达的信息添加了什么含义。

　　　　5.测试人员会对本身发现的缺陷不会在下一版本中进行修复而感到失望。

　　　　　　没有人但愿本身的工做被忽视。可是要尽量区分开忽视某些缺陷和有意识地选择不修复某些缺陷的行为。

　　五、作出反应

　　　　对缺陷正确的反应是：发现（find）他们；评估（figure）他们；修复（fix）他们。项目早期，会这样作。可是发现的缺陷愈来愈多，咱们应该如何作出反应？

　　　　除了从一开始就采起正确的项目管理作法，没有那种反应能够挽救项目。若是项目进行到测试以前都没有得到良好管理，大部分良好的反应都没法使用。

　　　　5.1 运气很差？管理不善？

　　　　成功项目和失败项目对比，是管理不良致使项目失败。

　　　　因外部缘由破坏软件配置，经过恢复安全的备份，便可以投入工做。团队一半成员请病假，结对编程和技术评审提供的冗余信息，容许人们继续在关键路径上工做。　　

　　　　5.2 项目赶进度的缘由

　　　　主要同管理的质量有关。

　　　　管理不良的软件项目具备以下特征。

　　　　1.经理们不了解测试、查明和除错之间的区别。

　　　　2.因为不了解这些区别，因此认为这些在项目中遇到的大部分问题都是测试致使的。

　　　　3.因为他们会认为测试会致使问题，更倾向于尽量推迟全部类型的测试。

　　　　4.因为他们选择在开发过程当中推迟测试，测试成为了第一次进展不利的时候。

　　　　5.因为选择在开发过程当中推迟测试并出现信息免疫，即使测试发现问题还继续伪装一切顺利。

　　　　6.因为他们出现了信息免疫，在项目早期的各个阶段一切都会看上去进展“顺利”。

　　　　7.因为经理们出了问题，缺陷到后期测试的时候才会显现出来，而其中不少从最初的需求开始就隐藏在产品中。

　　　　8.因为整个系统中的缺陷不少都难以查明，因此很难应对大部分的缺陷。

　　　　9.开发人员在最后期限的压力下试图修复新发现的错误，同时也会制造新的错误，他们脾气上升，缺勤增多，同时会议也越开越长，开发策略事与愿违。

　　　　10.因而参与者得出结论：“测试以前没有任何问题，是测试弄糟了全部事情”

　　　　错误管理的其余类型包括：过于雄心勃勃的承诺，太差的工具、人员职位安置不当。全部这些都会形成进展缓慢，致使最后削减测试和修改的时间。

　　　　对缺陷最初也是最重要的反应是要预见他们会出现。没人会侥幸地不遇到缺陷，因此从项目一开始就采起正确的作法。

　　　　最那些少许遗留下来的缺陷，当即开始FFF（发现-评估-修复）方法。

　　　　5.3 接近项目结束时应如何反应

　　　　管理良好的项目中，在交付日期临近时仍然存在一些缺陷，按照以下方式进行。

　　　　1.中止全部测试，开始为最后阶段作计划。

　　　　2.根据重要性对剩余的已知故障排序。

　　　　3.估算剩余的时间内，按照重要性由高到低能够修复多少缺陷。

　　　　4.从交付计划中去掉没法修复的特性。

　　　　5.若是步骤4中有些特性会让产品变得不可接受，就取消交付并从新制定交付计划。

　　　　6.接下来按照步骤2中肯定的缺陷重要性进行修复。

　　　　5.4 对测试所需时间的估算与现实差距很大的缘由

　　　　项目开始时的不良估算极可能是在项目结束时要赶进度的一个缘由。常见的计划偏差以下

　　　　1.好天气偏差

　　　　按照项目按计划进行，没有缺陷进行修复来估算时间。

　　　　2.不切实际的过程模型

　　　　会忽略掉查明缺陷、修改缺陷，而后从新测试缺陷的时间。

　　　　3.低质的过程数据

　　　　4.没有过程数据

　　　　5.5 错过全部能够改变的时刻应该怎么办

　　　　1.按照现状交付产品；2.把故障当成一种特性；3.能够向用户提出有关这些故障的警告；4.能够撤回某些部分或者整个产品；5.能够从问题开始的地方从新开始。

　　　　5.6 相关常识

　　　　1.运气老是宠爱管理良好的项目。

　　　　2.不要由于赶进度而减小分配给测试的时间和资源，若是不关心质量，为何还要测试。

　　　　3.在测试提供了有关产品实际状态的信息后应调整进度和估算的时间。

　　　　4.注意收集过程数据。对犯错的位置和时间越了解，就越容易发现、查明、定位和修复他们，或者在下一次出现相似的状况避免错误。

　　　　5.测试在产生项目概念甚至更早的时候就已经开始了。若是不了解这一点，就根本没法了解测试。