软件测试测试中的非正式沟通之走廊对话的法则
作者:网络转载 发布时间:[ 2010/10/8 10:31:26 ] 推荐标签:
亚当说:“那么你如何控制测试呢?你有没有一个测试计划呢?”
这是一个普遍存在的误解,是一个过程仅仅是由有文档的计划控制的。这是我引入另一种思维方式的机会。詹姆斯说:“在大多数情况下,我们使用一种探索的,基于风险的检验方法。
如果是基于你所说的引导测试过程的‘测试计划’,是的,我了解它了。除非它值得记录否则我不会写在我的记事本上,但是如果你想听的话我可以和你分享。
事实上,我希望你能够告诉我,我们的计划是否是在正确的轨道上,我们通过经常报告我们的测试状况,然后调整我们的测试策略,这些都是基于管理者对于产品风险的节点控制的。换句话说,作为我们测试过程中的一个客户,我希望你能参与到我们是如何控制测试的事情中。”
类似“探索的”和“基于风险的”这样的词语是强意词也是诱饵,我希望能够挑起他询问更多的关于我们如何测试的问题,但是这也是一个危险的动机,如果我的语气过分的强硬,给人放烟雾弹的印象。
亚当说:“什么是探索性测试方法?”
他受到诱惑了!他可能会怀疑我在欺骗他。但是对他是有益的,引起了他的注意。现在我想总结的解释和结束于一个强有力的建议,那是他这样做了可以得到他想要的东西。
詹姆斯说:“这好像在玩产品的‘二十个问题’。我们经过一系列的测试,
我们同时学习产品、设计测试,执行并报告缺陷,我们的测试覆盖是基于一个产品模型,该模型和我们以前的相比是有所改进的。我们也会使用启发式的测试列表,并且我可以现在将它们展现给你如果你想了解,这是我所了解的测试一种新的不熟悉的产品的快方法。你希望再将它们加快吗?那么让我们开始让测试者快速的了解该产品是什么和如何工作吧,让我们用一个小时时间让测试人员简要了解产品,然后再花费一小时用在质量保证。然后当你在两周内将讲代码提交给我们后我们会开始集思广益的讨论,产生更多的明确的测试策略。这样如何?”
亚当说:“什么时候我们才能知道整个测试过程需要多长时间?”
詹姆斯说:“告诉你吧,亚当。让我们现在坐下来,然后仔细的检查所有的因素:风险、各种测试任务、开发任务?这是全部吧。我们可能会找到简化测试过程的方法,但是我们应该也要开发一些其他可供选择的案例,尽管我们不希望测试和修复过程拖延。”
在这种情况下,他说什么其实都无关紧要。这是我后和好的提议,我想让他得到他想要的,而且它的代价通过分析变得艰难前行,如果他拒绝了我的建议,我所解释的所有事情仍然都是真实的。后,如果组织决定将测试压缩为“整整”五周时间,我将会做我能做的事并且真实的报告我的处境。我们或者是到那时之前都是完整无损,或者是在我们对于产品了解不多的时候将它推出。
这是一个典型的走廊会话,在自然环境中的解释说明。它可能发生在一个项目会议中而不是走廊,但是原理是一样的。注意这与你是否同意我的规则或者使用我的任何关于测试的想法是没有关系的,加入你自己的想法。在这里我所阐述的是在这样的解释说明中如何交换意见和形成它的力量因素是什么。关键点是,我们很少会用超过几句话解释我们的工作,这是为什么有一些例子说明(比如
缺陷的不好的例子)或者一个比喻(如“二十个问题”的游戏)是非常重要的。这是为什么这有助于实践得出影响的因素,这些因素将会使得你的测试失常。
没有什么能够替代实践,但是这些知识可以帮助你建立自己的对话技巧。两个帮助我成为一个更为有效的解释者的是Gerald Weinberg 的“解决问题探讨会”和“转变”,这些涵盖了整个做技术的小组。
一个好的走廊对话有九个法则:
1、从实践中发言。保持真实,拥有自己的方式。如果你没有完全明白其他人的言谈避免使用它,因为持怀疑态度的听众将会反复询问你,使它成为正在进行的项目以改善你对于测试技术的理解,通过将它们用于实践观察你是如何改变自己得想法的,并且使得你的想法影响其他人的实践。
2、和他们联系起来。比你的听众在某方面先进,将自己的身份放低。一个执行副总裁关心什么?一个技术支撑管理人员的是什么?一个项目经理的首要担心的三个问题是什么?将你的企图、知识和感兴趣的方面调整到你听众的一边。
3、查看你的条款。很多次我的解释说明已经挫败了意想不到的分歧术语。条款如测试、测试用例、测试计划、回归测试和缺陷,这些我称之为危险术语,因为对于这些条款有很多不同的定义。如果你辩证的看待自己,考虑像以前一样简要定义这些条款。
4、展示出尊重。对待每个人好像他们都是非常聪明的人,并且他们和你一样的关心质量。尊重异议和问题,我发现我有时候可以将处于敌对状态的听众通过善意的,有洞察力的解释转变过来,这和他们是否真的有企图和有洞察力是没有关系的。我用这种方式对待他们,因为不这样做肯定会失败。
5、引出有趣的话题。你不可能向一个不感兴趣的人有成果的解释事情。引起你的听众一点的兴趣他会提出问题。如何这样做的方法之一是抛出一些显而易见的不清楚的地方、行话或者和你的解释说明矛盾的地方,如果你的听众询问他们,你回答说“好眼光,我非常乐意听到你这样询问,这是个非常重要的问题。”如果他们不询问,他们说“你或许没有注意到这里有一个矛盾的地方,你将有权提出质疑?”不论是那种方式,继续将该问题更好的解释。
6、解释问题发生后的事情。按照你的想法做了执行的差异是什么?你希望发生什么?如果我们接受了你的测试观点我们行为有何不同?将注意力集中在你解释后面的任务上。
7、迅速一点,找到关键。使用简短的语句,那么也许你可以完成你的解释,而不是在妙语连珠以前被阻止。
8、展示出人人如何参与。我尽自己大努力将项目的情况真实的描述:我们都在一起,我们都有贡献,如果事情出错了我们共同承担。如果你发现解释每个人所扮演的角色比较困难,那么停下来思考你是否能够成功的解释这个项目。如果只是牵扯你一个人,那么你将会使你的听众厌烦,如果只是牵扯进他们,那么你听起来像是插足了不是你的业务范围的领域。
9、准备充分。开发多种解释的标准、预先的比喻以及不明白的时候要记录。解释测试的想法经常是在我真正在测试时,所以我准备了一个记事本用来捕获这些想法,现在我有一大堆的记事本,上面写满了解释的片段。
相关推荐
最新发布
性能测试之测试环境搭建的方法
2020/7/21 15:39:32软件测试是从什么时候开始被企业所重视的呢?
2020/7/17 9:09:11Android自动化测试框架有哪些?有什么用途?
2020/7/17 9:03:50什么样的项目适合做自动化?自动化测试人员应具备怎样的能力?
2020/7/17 8:57:06几大市面主流性能测试工具测评
2020/7/17 8:52:11RPA机器人能够快速响应企业需求,是怎么做到的?
2020/7/17 8:48:05Bug可以真正消灭吗?为什么?
2020/7/17 8:43:03软件测试基本概念是怎么来的?软件测试生命周期的形成历经了什么?
2020/7/16 9:11:10