左手测试,右手QA

发表于:2011-10-25 13:38

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:zdlzx    来源:51Testing软件测试博客

分享:

  在我们的团队中,QA角色身兼两职:测试和过程改进。以往我们对新进来的员工的期望值是先承担测试任务,在能较好地完成测试任务之后,才考虑让他参与一些SQA的工作。因此,有些已经进来大半年的同事,感觉对SQA还是没有什么概念,更没有机会去实践。或者有的同事想参与一些SQA的工作,却感到没有头绪,不知如何下手。而实际工作中我发现,QA的能力可以在每日工作中从点滴、从最开始就培养,这个与以往有没有SQA的知识和经验没有关系。因为简而言之,QA的工作主要围绕持续改进展开。而无论你是否有经验,每天的工作中你都在以自己独特的视角看问题,并可能看到改进的空间。那么,测试人员如何在日常工作中去逐步培养自己的QA能力呢?

  1、找到问题

  感受到一个问题,有时是出于关怀,你发现有人/自己正因为某件事情而痛苦;有时是出于怀疑,你发现有件事情和你想象/预计的不一样;还可能是出于直觉。但感受到问题其实并不是一件容易的事情。

  如果感受不到问题,我们可以试图通过多种方法积极寻找。

  如果你刚到一个项目组,提不出问题,可以先去听听别人(项目组成员、用户等等)的抱怨,或者想想自己痛苦的地方(比如找不到文档,系统操作不直观学习起来困难等等),这些就可能是问题。另外,为了培养自己找问题的习惯,可以给自己一个定量目标,每周去总结一个“疑似问题”。经过实践,这个带点自我强迫的方法对于找问题很有帮助。比如,虽然你的测试用例经过了和开发人员的评审,但是测试时你却发现几个重要的分支或者逻辑还是在代码中忘记实现了。除了报告缺陷,是否还有什么有共性的问题存在,并值得改进呢?

  如果你在一个项目组大家合作得不错,似乎没有什么问题,但一个看似不错的结果其实可能隐藏了问题。比如,完成工作,交付高质量的软件产品可以通过多种渠道实现,而非一定体现了高质量。可能是牺牲了时间进行好几轮的测试和修复和全面的回归测试,又或者某一块有一个英雄人物能够以一己之力确保这块没有问题。又如,虽然大规模代码重构的时候,内部测试能找到大部分重要的缺陷,但是否测试人员心理还是很抗拒和没底的?虽然这些问题不是单靠测试人员就能改善或者达到,但找到影响质量的问题确实需要测试人员的独立视角和贡献。如果一个测试人员、一个测试团队能够跳开测试的圈圈,从更广阔的角度看到影响质量的其他环节,帮助开发人员克服一些老的制约生产力和质量的毛病或者习惯,从而提高开发团队的水平,而更高开发水平的开发团队又对测试团队会提出更高的要求,那么这样的良性互动是我们都想看到的。现在被大家所广泛追捧的敏捷开发就提倡忽略角色的分工,大家一起为质量贡献自己的一份力量。

  前面说的是流程方面的问题,其实即使是被测程序的问题也存在于在整个软件开发周期。虽然传统对测试的理解是测试找问题更多集中在执行阶段,但借用QA的预防为主的思路,程序的问题也可以通过对需求和设计的评审及时发现和纠正,避免后期更大的浪费。

  2、探究问题

  感受到问题之后,需要一种探寻真相的精神去一探究竟。很多人能感受到问题,但是很遗憾地是当有更具体的任务在手头的时候,往往就忽略了这个问题。或者知道问题很大,也知道有各种原因的阻碍,因此采取放任自流的态度。这里要介绍一个好的习惯,就是把你当前没有时间去细想的问题先记录下来,以后再找机会去跟踪执行。类似outlook的任务或者一些桌面电子便签等工具可以帮助你设定任务及提醒执行。除了记录,还有一个好习惯就是去外部寻找一些同行的交流。如果看到同样/类似的话题,相信会驱使你有更大的兴趣去看自己碰到的问题,也启发你从不同角度看问题。

  QA的工作更多的针对的是有共性的问题,所以对这类问题的探究往往需要多个样本。换言之,在报告每一个缺陷的时候我们是在做测试,而对测试结果进行总结、归类、抽象出背后共性的问题则向QA靠近了一步。

  3、判断问题

  3.1 判断一个问题是否真的是问题

  测试人员通常看到实际执行结果后就能马上判断出其与预期结果之间的差异,从而判断是否存在问题。但过程改进相关的问题就没有那么一目了然了。比如,我们收到一个来自生产环境的缺陷,是因为一个需求变更的影响点大家都没有想到,直到生产环境暴露出来。开会的时候有人提出我们的开发流程不完善,如果能够建立起需求、设计和测试用例的跟踪矩阵,那么在做影响分析的时候就能顺藤摸瓜,避免此类问题了。听起来不错,是么?可是,如果我们细想,这种类似问题在生产环境对用户的影响大么?可以绕过去么?此类问题出现的次数多么?如果我们建立这个跟踪矩阵,维护代价有多高?前提还是我们首先要想到所有的内在联系(而这个本身就是无法确保的)。两相权衡,“没有这个跟踪矩阵”是我们现在的问题么?

  “判断一个问题是否真的是问题”最好能广泛听取不同的意见,并找到根源。

  3.2 判断一个问题是否需要被马上解决

  “判断问题是否需要马上解决”在某种程度上这有点象测试人员去设定缺陷的优先级。虽然所有被发现的缺陷都被记录,但是当前版本需要修复的或者可能只是其中一部分,而这一部分中还有需要尽快修复的和可以稍后修复的差别。过程改进的问题也是一样,有个主次和优先级之分。

21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号