作者在白板前介绍测试任务,然后在白板上写下Bugs和Issues/Questions。
如果求职者过于谨慎,在测试过程中没有在Bugs下有任何记录,或者过于自信,不认真考虑具体的实际情况,将自己发现的问题都记
录为bug,我都会特别关注。我希望在谨慎和自信直接找到一个平衡点。
然后作者给求职者一台笔记本电脑,上面有一个目录存放着被测软件,软件目录如下:
作者让求职者开始进行测试,并在进行过程中接受求职者的提问。在项目模拟过程中,作者关注求职者的以下一些能力:
Questioning:他们是否通过提问来构建他们的测试,还是直接进行测试
Resourcing:他们是否索要项目相关的文档、用例、邮件的资源
Modeling:他们如何关注提供测试的目录?是否打开每一个文件夹?并对每一个进行提问,并围绕他们设计测试
Conjecturing:推断,如果他们没有向我进行提问,他们对产品的设想是如何的?并且如何进行测试?
作者在求职者的测试过程中寻找所谓的“The 3 C’s”:caution, critical thinking, and curiosity。
如果他们向我进行提问,我们会以开发、项目经理、测试lead、CEO等角色中的一个对他们进行回答。有时作者会给以善意但是误传消息的回答,有时回答又会自相矛盾,这些都是真实项目中会出现的情况。
作者的目标是观察求职者的技能,并使他们陷入作者自己或者身边的人曾经遇到过的困境。通过这些面试,作者总结了最常见的10种使测试人员陷入困境的行为趋势:
测试人员对利益相关者过分的信任,认为他们拥有所有必须的信息,并且所有他们提供的信息都是正确和中肯的。
如何避免:尽可能多的形式收集信息:阅读、提问、交谈、测试...
思维局限性,测试人员仅从自己的或者近似的视角出发考虑问题,而没有用其他的、对立的或者正交纬度的视角出发,这样会导致漏掉一些
测试人员没有意识到诸如“回归测试”、"测试用例"、"功能"、"特性"等对不同的人来说意味着不同的事情。结果会导致,测试人员自认为测
如何避免:牢记相同的单词可能有不同的含义,使用与你作为测试人员所服务的合作伙伴角度出发最合适的定义来理解。
非注意盲视,和思维局限性有所不同,测试人员以自己的视角发现了某些事情,但是却没有处理这些信息,而是直接忽略了。
由于困惑而驳回自己的意见,测试人员不自信,认为开发软件的人员比自己更聪明,导致问题的不是软件本身的bug。
如何避免:尝试P.I.Q.cycle:Plunge-In-and-Quit,从某处开始考虑一个问题,当思考的过于复杂或者抽象而让你头疼的时候,退出来休息下,然后回来以新的视角考虑这个问题
功能狂热,只通过对UI判断,程序能做什么、不能做什么,以此来直接进行测试。而不考虑程序的构成、如何运行、如何被使用及有哪些依赖项。
测试人员没有从合作伙伴的角度评估自己的工作。给合作伙伴提供了不准确的信息:bug报告、测试说明等。
如何避免:test your testing,评估自己的测试技术、策略、计划、风险等
Oracles 指识别问题的原理和机制。这里相当于用例是否通过的标准。测试人员使用了错误的标准或者不知道使用什么标准来评判一个用例是否通过。