10种使测试人员陷入困境的行为趋势

10种使测试人员陷入困境的行为趋势  

这篇文章的作者是著名软件与网络测试实验室Quardev的高级顾问，做过测试经理、测试承包商、为微软等公司做过顾问，并为很多杂志写过文章，且时常在各种测试大会中做演讲。在10年的时间中作者组织、管理了超过400次的测试岗位面试，这些面试都是以项目模拟的形式进行的，从对这些面试中面试者的表现，作者总结了限制测试人员发挥其测试技能的10种倾向，并提出了如何避免这些倾向的建议。

　　作者组织这些面试的目的是让面试者们暴露他们的优势与不足，从而决定他们是否适合在Quardev的工作。面试的流程如下：先是通过电话面试了解求职者的工作经历，然后通过邮件提供给求职者一个产品，并要求在20分钟之类对其进行测试写出至少一个bug。接下来，会邀请求职者去实验室，对他们的工作经历进行一次面对面的深入调查。项目模拟是最后一步，项目模拟的过程如下：

　　作者在白板前介绍测试任务，然后在白板上写下Bugs和Issues/Questions。

　　求职者在Bugs下记录他们发现的问题，每条记录必须少于20个单词。Issues和Bugs的区别在于，测试人员可能不是很确认这是否是一个bug，他们不确定是否原本就是这么设计的。比如"在主目录下没有setup.exe"，事实上可能是一个bug。这与求职者对于程序设计原理的了解程度和自信心等级有关。

　　如果求职者过于谨慎，在测试过程中没有在Bugs下有任何记录，或者过于自信，不认真考虑具体的实际情况，将自己发现的问题都记

　　录为bug，我都会特别关注。我希望在谨慎和自信直接找到一个平衡点。

　　作者告诉求职者，当他们发现一个问题的时候有三个选择：1）记录为一个bug；2）记录为一个issue；3）提一个问题。然后作者写下Test Ideas和Tests Run。Tests Ideas是由于执行时间过长而不当场执行的测试，Tests Run则是求职者当场执行的测试。

　　白板上的内容如下图：

　　然后作者给求职者一台笔记本电脑，上面有一个目录存放着被测软件，软件目录如下：

　　这是一个检查三角形类型的程序，输入用逗号隔开的3个数字，点击Check按钮后，会有5种可能的输出：“scalene” (three unequal sides), “equilateral” (three equal sides), “isosceles” (two equal sides), “invalid”, and “Not a Triangle.”。软件的UI如下：

作者让求职者开始进行测试，并在进行过程中接受求职者的提问。在项目模拟过程中，作者关注求职者的以下一些能力：

　　Questioning：他们是否通过提问来构建他们的测试，还是直接进行测试

　　Resourcing：他们是否索要项目相关的文档、用例、邮件的资源

　　Modeling：他们如何关注提供测试的目录？是否打开每一个文件夹？并对每一个进行提问，并围绕他们设计测试

　　Recording：测试过程中是否进行记录

　　Conjecturing：推断，如果他们没有向我进行提问，他们对产品的设想是如何的？并且如何进行测试？

　　作者在求职者的测试过程中寻找所谓的“The 3 C’s”：caution， critical thinking， and curiosity。

　　如果他们向我进行提问，我们会以开发、项目经理、测试lead、CEO等角色中的一个对他们进行回答。有时作者会给以善意但是误传消息的回答，有时回答又会自相矛盾，这些都是真实项目中会出现的情况。

　　作者的目标是观察求职者的技能，并使他们陷入作者自己或者身边的人曾经遇到过的困境。通过这些面试，作者总结了最常见的10种使测试人员陷入困境的行为趋势：

　　10、Stakeholder Trust

　　测试人员对利益相关者过分的信任，认为他们拥有所有必须的信息，并且所有他们提供的信息都是正确和中肯的。

　　如何避免：尽可能多的形式收集信息：阅读、提问、交谈、测试...

　　9、Compartmental Thinking

　　思维局限性，测试人员仅从自己的或者近似的视角出发考虑问题，而没有用其他的、对立的或者正交纬度的视角出发，这样会导致漏掉一些

　　系统级的bug，或者漏测某个完整的特性。

　　如何避免：尝试Brute Cause Analysis

　　8、Definition Faith

　　测试人员没有意识到诸如“回归测试”、"测试用例"、"功能"、"特性"等对不同的人来说意味着不同的事情。结果会导致，测试人员自认为测

　　试已经完整了，而实际上测试却还没开始。

　　如何避免：牢记相同的单词可能有不同的含义，使用与你作为测试人员所服务的合作伙伴角度出发最合适的定义来理解。

　　7、Inattentional Blindness

　　非注意盲视，和思维局限性有所不同，测试人员以自己的视角发现了某些事情，但是却没有处理这些信息，而是直接忽略了。

　　如何避免：全面获取信息，而不是指关注自己认为会引起问题的那部分。situational awareness态势感知，在大规模系统环境中，对能够引起系统态势发生变化的安全要素进行获取、理解、显示以及预测未来的发展趋势。

　　6、Dismissed Confusion

　　由于困惑而驳回自己的意见，测试人员不自信，认为开发软件的人员比自己更聪明，导致问题的不是软件本身的bug。

　　如何避免：增加自信，遇到困惑的时候提出问题或者记录下来

　　5、Performance Paralysis

　　面临选择的时候害怕犯错而迟疑不定。

　　如何避免：尝试P.I.Q.cycle：Plunge-In-and-Quit，从某处开始考虑一个问题，当思考的过于复杂或者抽象而让你头疼的时候，退出来休息下，然后回来以新的视角考虑这个问题

　　4、Function Fanaticism

　　功能狂热，只通过对UI判断，程序能做什么、不能做什么，以此来直接进行测试。而不考虑程序的构成、如何运行、如何被使用及有哪些依赖项。

　　如何避免：使用启发式思考或者checklist

　　3、Yourself， untested

　　测试人员没有从合作伙伴的角度评估自己的工作。给合作伙伴提供了不准确的信息：bug报告、测试说明等。

　　如何避免：test your testing，评估自己的测试技术、策略、计划、风险等

　　2、Bad Oracles

　　Oracles 指识别问题的原理和机制。这里相当于用例是否通过的标准。测试人员使用了错误的标准或者不知道使用什么标准来评判一个用例是否通过。

　　如何避免：听取其他合作伙伴的已经，以判断问题是否为bug。

　　1、 Premature Celebration

　　提前庆祝，发现问题后不深入寻找原因，而是提前抛出问题。

　　如何避免：遇到问题立即进行分析推断，而不是马上下定论。